This is the first time I've heard this, and I've been looking at license
questions for a bunch of months lately (admittedly just scratching the
surface). So it's a very interesting wrinkle.
The implication, if I understand it correctly, is that when I find software
that has a BSD license, I have no way to tell from the license whether or not I
can actually use the software? Because the license itself doesn't say whether
the software is patented. So even though I have a license that grants me usage
privileges, you/they are saying that in fact it doesn't give me those
privileges, because a patent may simultaneously apply -- or even be granted
later? This seems quite counter-intuitive.
I do recognize that the BSD license is short, and does not explicitly grant
many particular rights that other licenses do. The lack of such detailed
explicitness is interpreted as an advantage of BSD by many, since it doesn't
look to take 3 lawyers to understand. To conclude that the right to *use* is
in some way limited by this lack of detail is an interesting hypothesis, but
I'm not sure I believe it, unless we have some kind of legal consensus (or
better yet, an actual ruling) to refer to.
Could you please point to some on-line material that indicates this is the
case? Ideally material not written by Apache folks, just so we can understand
how much of this is common knowledge in the community
John
On Dec 11, 2010, at 09:47, Mattmann, Chris A (388J) wrote:
> Hi James,
>
> Just a little bit more clarity too. The main difference between BSD and ALv2
> has to do with patents. After discussing this with some ASF members, it seems
> that BSD doesn't grant a downstream user of your software any patent rights.
> So software distributed under the BSD license can be (knowingly) patented by
> the inventor - and, in order to use the software, downstream users have to
> license the patent independently of the BSD license. On the other hand ALv2
> means that if the original inventor of the ALv2 licensed software has a
> patent on that software, then the owner must provide you as a downstream user
> of the ALv2 licensed software a patent license. Of course, nothing stops
> someone who isn't involved having a patent covering that software and suing
> you for infringement, but that's an aside.
>
> Hope that helps to clarify some of the differences between the two.
>
> Cheers,
> Chris
>
>
>
> On Dec 10, 2010, at 8:28 PM, Gallagher James wrote:
>
>>
>> On Dec 10, 2010, at 8:38 PM, Mattmann, Chris A (388J) wrote:
>>
>>> Hi Dennis,
>>>
>>>> We recently changed the opendap license to the one you
>>>> currently see because James felt uncomfortable using the
>>>> Apache license.
>>>
>>> I was wondering what made James feel uncomfortable about using the
>>> ASLv2 license?
>>
>> Nothing. Mathworks needs BSD on code they redistribute and changing/
>> adding licenses takes time. I know that ASLv2 and BSD are compatible
>> in a way that will let our code work with it, so I'm solving several
>> problems at once (with a single change). If I felt that we had code
>> that would benefit from inclusion in the Apache OS framework, I would
>> have chosen that - and we might, but I don;t have time to sort out
>> these things right now.
>>
>> So my decision is no slight to Apache - I think the Apache Foundation
>> is doing some really great things.
>>
>> James
>>
>>>
>>>> Is there something about that license
>>>> that makes it unsuitable for your use?
>>>
>>> Not sure, but trying to figure out why the ASLv2 isn't being
>>> considered? In my experience it's quite flexible in terms of
>>> redistribution, commercialization, and attribution issues in FOSS
>>> software, which are all important things to consider as a downstream
>>> user of FOSS.
>>>
>>> Cheers,
>>> Chris
>>>
>>>> Mattmann, Chris A (388J) wrote:
>>>>> Hi James,
>>>>>
>>>>> Are you able to provide an OPeNDAP java release under the Apache
>>>>> Software License, v2 [1]? That would *really* make OPeNDAP useable
>>>>> in a number of Apache projects that I'd love to use the API in
>>>>> (incl. Tika directly).
>>>>>
>>>>> Currently it looks like it's some BSD-style license [1].
>>>>>
>>>>> Cheers,
>>>>> Chris
>>>>>
>>>>> [1] http://www.apache.org/licenses/LICENSE-2.0
>>>>> [2] http://scm.opendap.org:8090/svn/trunk/Java-OPeNDAP/COPYRIGHT
>>>>>
>>>>> On Dec 7, 2010, at 12:18 PM, Gallagher James wrote:
>>>>>
>>>>>> On Dec 7, 2010, at 1:13 PM, Martin Desruisseaux wrote:
>>>>>>
>>>>>>> Hello all
>>>>>>>
>>>>>>> I have been silent for a long time, busy on other tasks. But now
>>>>>>> I would like to work on this Maven Central task (it is a blocker
>>>>>>> issue for Geotoolkit.org release).
>>>>>>>
>>>>>>> Since we can not fix the 4.2 deployment, I suggest to create a
>>>>>>> new release: 4.2.1. This release would contains only two
>>>>>>> artifacts in the edu.ucar group.
>>>>>>>
>>>>>>> • unidatacommon, which has no dependency.
>>>>>>> • netcdf, which depends on the following:
>>>>>>> • unidatacommon
>>>>>>> • slf4j-api
>>>>>>> • slf4j-jdk14 (by default, user may exclude this
>>>>>>> dependency
>>>>>>> and choose an other one).
>>>>>>>
>>>>>>> I think that the following dependencies are optional, most of
>>>>>>> them required only if we use OpenDap. Can someone confirm please?
>>>>>>>
>>>>>>> • bufrTables
>>>>>>> • opendap
>>>>>>> • jdom
>>>>>>> • commons-httpclient
>>>>>>> • commons-codec
>>>>>>> • commons-logging
>>>>>>> • ehcache
>>>>>>>
>>>>>>> Given that we have not yet sorted out the OpenDap licensing
>>>>>>> issue, I suggest to leave OpenDap and its dependencies out for
>>>>>>> now, and maybe add them in a 4.2.2 release. Does anyone agree
>>>>>>> with this plan?
>>>>>> A while ago I asked Dennis to change the license on the opendap
>>>>>> software specifically so that it could be included. If there's
>>>>>> another issue, or if time is tight, I certainly understand.
>>>>>> However, if licensing is the only reason, that problem has been
>>>>>> resolved AFAIK.
>>>>>>
>>>>>> James
>>>>>>
>>>>>>> There is a proposal for the unidatacommon pom.xml file:
>>>>>>> http://hg.geotoolkit.org/netcdf-deploy/file/tip/unidatacommon.xml
>>>>>>> I will update the netcdf pom.xml proposal after we get
>>>>>>> confirmation of the minimal set of dependencies.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Martin
>>>>>>>
>>>>>> --
>>>>>> James Gallagher
>>>>>> jgallagher at opendap.org
>>>>>> 406.723.8663
>>>>>>
>>>>>
>>>>>
>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>> Chris Mattmann, Ph.D.
>>>>> Senior Computer Scientist
>>>>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>>>>> Office: 171-266B, Mailstop: 171-246
>>>>> Email: chris.a.mattmann@xxxxxxxx
>>>>> WWW: http://sunset.usc.edu/~mattmann/
>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>> Adjunct Assistant Professor, Computer Science Department
>>>>> University of Southern California, Los Angeles, CA 90089 USA
>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>
>>>
>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>> Chris Mattmann, Ph.D.
>>> Senior Computer Scientist
>>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>>> Office: 171-266B, Mailstop: 171-246
>>> Email: chris.a.mattmann@xxxxxxxx
>>> WWW: http://sunset.usc.edu/~mattmann/
>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>> Adjunct Assistant Professor, Computer Science Department
>>> University of Southern California, Los Angeles, CA 90089 USA
>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>
>>
>> --
>> James Gallagher
>> jgallagher at opendap.org
>> 406.723.8663
>>
>>
>>
>>
>
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Chris Mattmann, Ph.D.
> Senior Computer Scientist
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 171-266B, Mailstop: 171-246
> Email: chris.a.mattmann@xxxxxxxx
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Adjunct Assistant Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> _______________________________________________
> netcdf-java mailing list
> netcdf-java@xxxxxxxxxxxxxxxx
> For list information or to unsubscribe, visit:
> http://www.unidata.ucar.edu/mailing_lists/
John Graybeal <mailto:jgraybeal@xxxxxxxx>
phone: 858-534-2162
System Development Manager
Ocean Observatories Initiative Cyberinfrastructure Project:
http://ci.oceanobservatories.org
Marine Metadata Interoperability Project: http://marinemetadata.org
