Re: License

[Jim Jagielski]

Justin Wells wrote:
> 
> The consensus on the list ([EMAIL PROTECTED]) has been 
> that you should draft a license which you think fits the definition
> and simply start using it. If your software is important enough to 
> draw attention, then sooner or later someone will be interested in
> seeing to it that your license is compliant. At that point one of
> the OSI principals would likely approach you and your license would
> wind its way through the approval process.
> 
> If you post your license to the license-discuss list you WILL likely
> get some useful feedback, but no approval, unless you are high 
> profile enough. In which case, go to Perens, etc., directly rather
> than via the list.
> 

Well, it appears to me that Apache is kinda important enough and
would have drawn at least some attention. But what do I know???

PS: Yep, I'm CCing to to [EMAIL PROTECTED]

-- 
=======
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
"Are you suggesting coconuts migrate??"

Re: [License-discuss] a Free Island Public License?

[Jim Jagielski]

On Dec 16, 2011, at 2:53 PM, Stephie King wrote:

> This definitely conflicts with the GPL, and may not qualify as open source.

One does not lead to the other...

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

Re: [License-discuss] [License-review] CC0 incompliant with OSD on patents, [was: MXM compared to CC0 ]

[Jim Jagielski]

On Mar 8, 2012, at 3:51 PM, Rick Moen wrote:

> 
> Pardon my interjecting, but I think you may have misread Russ's point.
> I _believe_ he was saying that, if a codebase is encumbered by patents
> not available royalty-free (e.g., only under 'RAND' terms), then the
> software in question ends up being effectively proprietary in
> jurisdictions where the patent is enforceable, irrespective of the
> software's licence -- as long as the software continues to implement the
> patented method, anyway:  Derivatives that no longer do that would be 
> open source if the licensing and other relevant facts permit.
> 

BTW: How is this different from, say, the US export control provisions?
In both cases, a codebase is encumbered by external, and "localized"
restrictions. So does this mean that software distributed out of
the US, no matter the OSI license, isn't "really" open source?
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] [License-review] CC0 incompliant with OSD on patents, [was: MXM compared to CC0 ]

[Jim Jagielski]

On Mar 9, 2012, at 11:23 AM, Rick Moen wrote:

> Quoting Jim Jagielski (j...@jimjag.com):
> 
>> BTW: How is this different from, say, the US export control provisions?
>> In both cases, a codebase is encumbered by external, and "localized"
>> restrictions. So does this mean that software distributed out of
>> the US, no matter the OSI license, isn't "really" open source?
> 
> During the period that the RSA algorithm was encumbered by a (somewhat
> weak and potentially challengable) patent in USA jurisdictions, mod_ssl
> was widely considered to effectively not be open source when deployed in
> the USA, yes.
> 

But that's not the point... the point is that if we are looking
at adjusting the OSD, or acceptance/validation of a license, based
on whether or not it addresses patents, then why aren't we also
worried about such issues as the export control, etc...

I see no difference between the statements "We can't approve this
because it doesn't address patents" and "We can't approve this
because it doesn't address the US export laws."

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

Re: [License-discuss] [License-review] CC0 incompliant with OSD on patents, [was: MXM compared to CC0 ]

[Jim Jagielski]

On Mar 9, 2012, at 1:25 PM, Rick Moen wrote:

> 
> Please note that I personally articulated no such position.

I certainly did not intend to imply you had...

Cheers!

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

Re: [License-discuss] New OSI FAQ items posted about Public Domain and CC0.

[Jim Jagielski]

++1
On Apr 3, 2012, at 9:44 PM, Lawrence Rosen wrote:

> Karl, those are excellent FAQ entries! They summarize quite well the
> non-consensus reached on our lists. Good work!  /Larry
> 
> 
> Lawrence Rosen
> Rosenlaw & Einschlag, a technology law firm (www.rosenlaw.com) 
> 3001 King Ranch Road, Ukiah, CA 95482
> Cell: 707-478-8932
> 
> 
>> -Original Message-
>> From: Karl Fogel [mailto:kfo...@red-bean.com]
>> Sent: Tuesday, April 03, 2012 5:54 PM
>> To: license-discuss@opensource.org; license-rev...@opensource.org
>> Subject: [License-discuss] New OSI FAQ items posted about Public Domain
>> and CC0.
>> 
>> (This seems appropriate for both license-discuss@ and license-review@,
>> so
>> I'm posting it in both places.)
>> 
>> I've been seeing an increasing number of inquiries about the public
>> domain and open source, and about CC0 and open source.  A few of those
>> inquiries have come here, but I'm also getting them elsewhere.
>> 
>> So I've tried to formulate good answers:
>> 
>>   http://opensource.org/faq#public-domain
>>   http://opensource.org/faq#cc-zero
>> 
>> I hope I've reflected the general consensus of the License Review
>> committee accurately, not made any legal mistakes, etc.  I'd appreciate
>> feedback on these.
>> 
>> The "public domain" entry is complex.  It felt wrong to simply say that
>> PD is not open source, when it clearly exhibits most or all of the
>> important properties of Open Source and is at least capable of meeting
>> the OSD; on the other hand, it is not a license and therefore cannot be
>> OSI-approved, and it has some portability problems.  So I've tried to
>> express all of that in the answer, and recommend that people use
>> OSI-approved licenses wherever possible.
>> 
>> The CC0 entry is more straightforward, but also would benefit from peer
>> review.
>> 
>> Please hold the flamethrowers, anyone who might be tempted to flame,
>> and
>> remember that these are inherently contentious and complicated
>> subjects!
>> It would be easier for the OSI to just say nothing on the topics :-),
>> but silence on these questions would not serve our mission very well.
>> 
>> Thanks,
>> -Karl
>> ___
>> 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] BSD, MIT [was Re: Draft of new OSI licenses landing page; please review.]

[Jim Jagielski]

On Apr 5, 2012, at 5:05 PM, Chad Perrin wrote:

> On Thu, Apr 05, 2012 at 02:48:38PM -0400, John Cowan wrote:
>> Chad Perrin scripsit:
>> 
>>> Before pushing such a change, perhaps we should consider the meaning of
>>> Apache 2.0 License section 4, subsections 2 and 4.  There's more to
>>> "permissive" than "isn't copyleft", and Apache is a somewhat less
>>> permissive license.
>> 
>> Those both have to do with making sure attribution (and blame) go to
>> the right people.  I don't see them as serious restrictions on reuse.
> 
> Like many of the worst laws contemplated in US Congress, it specifies
> implementation rather than principle.  This can cause problems, such that
> there are cases where it is inappropriate to use the license based on
> those clauses.
> 

Such as?

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

Re: [License-discuss] BSD, MIT [was Re: Draft of new OSI licenses landing page; please review.]

[Jim Jagielski]

On Apr 5, 2012, at 11:35 AM, John Cowan wrote:

> Luis Villa scripsit:
> 
>> Without getting into other issues, I'd hope we can agree that BSD/MIT
>> do not belong in a first-class list here in 2012. Apache fills the
>> same purpose[1] (permissive license) while being better drafted and
>> properly handling patents.
> 
> All true, and I greatly favor Apache.  But BSD/MIT are well-understood
> and still extremely pervasive.  Looking at Google Code, which was
> founded fairly recently, Apache dominates; looking at Sourceforge and
> Freshmeat, MIT and BSD dominate.
> 
> So put Apache before MIT/BSD, but don't drop them altogether.

-0... but just because something had been around for a long
time (BSD/MIT) is no reason to maintain it as a 1st class
citizen... The idea of a 1st class list is to "prioritize"
the better licenses for a class of licenses, and the ALv2
is "better" than BSD/MIT.
___
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.

[Jim Jagielski]

The problem/issue is that it is difficult to address licenses
without, imo at least, the "politics" of said license leaking
in.

It is difficult to write things without personal biases filtering
out, something which happens with me fwiw.

On Aug 17, 2013, at 8:59 PM, Bradley M. Kuhn  wrote:

>> Bradley M. Kuhn scripsit:
>>> 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.
> 
> John Cowan wrote at 09:49 (EDT):
>> Surely he jests.  Choosealicense.com *blatantly* pushes people toward
>> the MIT license.
> 
> :)  Fontana has been known to jest.
> 
> Still, my view is that it's tough to compliance about this; the
> choosealicense.com site says "patches welcome", so we should offer them.
> 
>> I don't believe, however, that my chooser 
>> has any such biases.
> 
> John, have you considered offering text from your license chooser as a
> patch to chosealicense.com?  I think it'd be good to test their claim
> that they want contribution, and you seem the right person to do it,
> since you've worked on this problem before.
> 
> -- 
>   -- bkuhn
> ___
> 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] Strong and weak copyleft

[Jim Jagielski]

Well, the FSF itself uses the concept of weak: For example,
when describing WxWidgets:

Like the LGPL it is a weak copyleft license, so we recommend it only in 
special circumstances.

So, at least according to https://www.gnu.org/philosophy/license-list.html,
the FSF considers LGPL as weak copyleft.
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] Proposal: Apache Third Party License Policy

[Jim Jagielski]

FWIW, I agree.

Again, there is a difference between, maybe, what we are allowed
to do and what we *should* do. OSI *might* be able to determine
what we legally can do (though I doubt that), but they have
not a clue (no disrespect) what our *policy* is as well as
the background and rationale behind that policy.

Letter vs. intent.

> On May 26, 2015, at 4:14 AM, Ross Gardler (MS OPEN TECH) 
>  wrote:
> 
> Once again this ignores the community motivations for the policy. The OSI is 
> not qualified to make judgments on ASF cultural mission.
> 
> Sent from my Windows Phone
> From: Lawrence Rosen
> Sent: ‎5/‎25/‎2015 11:54 AM
> To: legal-disc...@apache.org
> Cc: 'License Discuss'; Lawrence Rosen
> Subject: RE: Proposal: Apache Third Party License Policy
> 
> Hen,
>  
> An important part of the proposed Apache Third Party License Policy is that 
> we finally leave the sad domain of FOSS license compatibility determination 
> to our friends and experts at OSI.
>  
> If we have a question about whether a specific FOSS license "infects" Apache 
> code, ask OSI at license-discuss@opensource.org. That's not ASF's expertise. 
> Our PMCs and certainly our board of directors are not qualified to maintain 
> complex "A, B and X" lists of FOSS licenses and exceptions.
>  
> And so in open source, different organizations can play their own important 
> roles in our ecosystem. All this without turning one FOSS developer against 
> another FOSS developer here at Apache merely because of their choice of 
> wonderful FOSS license.
>  
> /Larry
>  
>  
> From: Henri Yandell [mailto:bay...@apache.org] 
> Sent: Monday, May 25, 2015 11:12 AM
> To: ASF Legal Discuss; Lawrence Rosen
> Subject: Re: Proposal: Apache Third Party License Policy
>  
>  
> Your original proposal was (quoting the heart of it; for any readers not 
> familiar refer back to the whole email):
> 
> Proposal: "Apache projects may accept contributions under ANY OSI-approved 
> open source license. Such software may now be included in Apache aggregations 
> that, as described above, will be licensed to the public under Apache License 
> 2.0."
>  
> An exception has evolved through the course of these threads, namely that 
> GPL/AGPL versions are an exception to that and not covered. That also means a 
> policy cannot approve 'ANY' as it's unknown what the next licence on the list 
> would be.
> 
> At this point the conversation is:
> 
> a) Removal of particular licenses on the 'cannot be used' list that are on 
> the OSI list. I think that's LGPL, QPL and Sleepycat licences. I don't think 
> either of the latter are used on software today, so I don't see a need to do 
> that. There are other licences on the OSI list that we don't have covered, so 
> it's possible there are some we would consider on the 'cannot be used' list. 
> This should become a thread on moving LGPL licences to either the 'weak 
> copyleft -> binary only' or 'can be used' list. The former makes more sense.
> 
> b) Moving the 'weak copyleft -> binary only' licences to the 'can be used' 
> list. That's a worthwhile proposal, but one that should take a pause and 
> restart. Starting with CDDL/EPL/MPL would make sense as the most popular on 
> that list (possibly individually). A lot of our use of those licences is 
> binary, so having that position has not been as impactful as might be 
> imagined at first.
>  
> Hen
>  
> On Mon, May 25, 2015 at 8:23 AM, Lawrence Rosen  wrote:
> Sam Ruby wrote:
> > You may not have been aware that it is an ASF problem to worry about 
> > whether downstream distributors can make derivative works -- Free and 
> > proprietary alike -- of our projects, but it is true.  As such, we care 
> > very much about the kind of dependencies a project takes on, and the 
> > license of code that we bundle.
> 
> Sam, of course I'm aware of that. That is precisely why I am requesting that 
> you change that antiquated policy.
> 
> Please remember, EVERYONE can make derivative works (free and proprietary 
> alike) of Apache projects even if that software includes EPL and MPL works. 
> What they can't do is to refuse to distribute derivative works of EPL and MPL 
> components under their original licenses. That is a reciprocal requirement. 
> But it doesn't prevent derivative works.
> 
> > EPL and MPL fall someplace in between.
> 
> In between what and what?
> 
> I've been challenged repeated here because certain GPL folks don't want their 
> license interpreted this way. So if Apache changes its obsolete policy for 
> every FOSS license except the GPL, I'll consider that a significant 
> accomplishment. I'll wait impatiently for the lawyers who are trying to 
> create a licensing exception for those GPL licensors that DO want their works 
> incorporated into Apache projects.
> 
> > And with that, I believe we have covered why the three categories in the 
> > third partly licensing policy can not be collapsed into one category.
> 
> No we haven't settled that at all. :-)
> 
> /.L

Re: [License-discuss] Proposal: Apache Third Party License Policy

[Jim Jagielski]

(dropping members@)

As Larry noted, the ASF board makes a distinction between what is
legally possible, and what our policy is. The rationale behind
that policy can easily be found. Larry's proposal would be a major
policy change for the ASF and, we (the ASF) are confident, would
cause major discussion and disruption and confusion to our end-users,
who now, for valid reasons, consider ASF code as "safe" and "brain-dead
easy" to consume and leverage.

> On May 26, 2015, at 10:16 PM, Lawrence Rosen  wrote:
> 
> [This has been a hellishly long thread on private Apache lists before the 
> board cut off discussion on revised policies. Below was the short start of it 
> I submitted over two weeks ago. Apache board members don't want to revise 
> current policy. Many Apache members don't want it. Still, it is a serious 
> proposal to bring some more freedom and cooperation to open source. Please 
> treat this as a political document for license-discuss@. /Larry]
>  
> **
>  
> DRAFT: Apache Third Party License Policy (May 10, 2015)
>  
> Apache projects have long been universal donors to many other software 
> projects around the world. We are proud of that. We intend to continue that 
> tradition by requiring that all software aggregations distributed by Apache 
> Software Foundation will be licensed to the public under the Apache License 
> 2.0. This means that all of our licensees around the world are free to:
>  
> ·   Use Apache software for any purpose.
> ·   Make and distribute copies.
> ·   Create and distribute derivative works.
> ·   Access and use the source code.
> ·   Combine Apache and other software.
>  
> In order to foster our Foundation community ethic to ensure the widest free 
> participation in the open source software community, Apache has now decided 
> to become also a universal acceptor of other open source software licensed to 
> us from around the world. 
>  
> When technically appropriate for that software in the judgment of the PMC, 
> Apache projects may accept contributions under ANY OSI-approved open source 
> license. Such software may now be included in Apache aggregations that, as 
> described above, will be licensed to the public under Apache License 2.0.
>  
> Because Apache projects may now incorporate third party open source software 
> into our software aggregations, we have added the following procedures for 
> Apache software releases:
>  
> ·   Because all Apache project contributions will be licensed to Apache 
> under an OSI-approved open source license, the above list of five fundamental 
> software freedoms continues to apply to all Apache software. Downstream users 
> and re-distributors of Apache software can continue to incorporate all of our 
> open source software into their own products unmodified without incurring any 
> special derivative work reciprocity obligations.
>  
> ·   All releases containing any non-Apache open source licensed 
> contributions will be explicitly identified in a NOTICE file that our 
> projects will create. The PMC is responsible to ensure that the text in the 
> NOTICE file expressly satisfies the notice and disclosure requirements of all 
> relevant contribution licenses.
>  
> ·   Modifiers and re-distributors of Apache software will now need to 
> read the NOTICE files to determine whether they have any derivative work 
> reciprocity requirements for specific contributions. 
>  
> You may influence the inclusion or exclusion of specific third party 
> contributions under OSI-approved licenses by joining the Apache project. All 
> such decisions are made by Apache projects in public.
> ___
> 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] [CAVO] SF - LAFCO open source voting draft

[Jim Jagielski]

> On May 27, 2015, at 11:53 AM, Patrick Masson  wrote:
> 
> I would also add that OSI approval creates trust.

I'd say more that trust. Let's be blunt: The legal issues related
to using, consuming and/or leveraging open source are legend.
Use of a non OSI-approved "open source" license is simply a
guarantee to spend huge amounts of billable hours having
one's legal team vet the license, if anyone even bothers to
*consider* a non-OSI license in the first place. An OSI approved
license lowers a LOT of barriers to entry.
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] International Licenses

[Jim Jagielski]

> On Jun 5, 2015, at 12:13 PM, Brian Behlendorf  wrote:
> 
> With regard to jurisdiction: do we have evidence that existing licenses can't 
> be enforced as per the intent of the license stewards in certain juridictions 
> because they use terms differently, or there are assumed defaults in that 
> jurisdiction that simply don't exist?  If so, wouldn't it be more aligned 
> with reducing license proliferation to work with existing license stewards to 
> iterate existing licenses to adjust their language (or add 
> jurisdiction-specific terms) to address these exceptions?
> 

I would agree that this effort should be done, but only provided that
there is evidence that things are currently broken. I don't think
it's quite fair "forcing" people into busy work to fix something that
isn't broken.

I wonder if the proposal is a problem looking for a solution, or a
solution looking for a problem.

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

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

[Jim Jagielski]

Personally, I am conflicted with the idea of exact conditions
and requirements of a LICENSE not being fully specified in
the LICENSE itself. It almost seems like a way to "get around"
at least OSI approval, plus it adds (IMO) confusion. It is
quite possible to have an OSI approved licensed s/w package
be made "non-open source" by careful crafting of the PATENTS
file, which bothers and concerns me.

> On Dec 1, 2016, at 11:26 PM, Richard Fontana  wrote:
> 
> 
> 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

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