- From: Jeff Jaffe <jeff@w3.org>
- Date: Wed, 05 Jun 2013 10:04:05 -0400
- To: Andreas Kuckartz <A.Kuckartz@ping.de>
- CC: Norbert Bollow <nb@bollow.ch>, public-restrictedmedia@w3.org
On 6/5/2013 9:02 AM, Andreas Kuckartz wrote: > Jeff Jaffe: >> On 6/5/2013 7:42 AM, Norbert Bollow wrote: >>> On 6/5/13, Jeff Jaffe <jeff@w3.org> wrote: >>>> EME, for example, might not be implementable in GPLv3. But I wasn't >>>> aware that it was not implementable in other open source licenses such >>>> as Apache or MPL (or even GPLv2 for that matter). What am I missing? >>> The distinction between an implementation coming with a license >>> document that is generally accepted as an open source license, and the >>> distribution terms as a whole (as arising from combination of that >>> legal document with other relevant realities of the legal system in a >>> given jurisdiction, such as whether relevant patent claims exist for >>> which no free license is available, whether there are restrictions >>> arising from the DMCA or similar legislation) complying with the open >>> source definition [1] or the Free Software definition [2] (the two are >>> equivalent for most practical purposes, including the current >>> discussion). >>> [1] http://opensource.org/osd. >>> [2] http://www.gnu.org/philosophy/free-sw.html >> I'm still confused. >> >> Are you saying that the open source definition can provide limitations >> on MPL and Apache that are not inherent in the MPL or Apache licenses? > The "distribution terms as a whole" as Norbert correctly writes can > include legal limitations which come from outside both the Open Source > Definition (http://opensource.org/osd) and the license itself. > > This might be legal. It might in some extreme cases even be intended by > the author of the license or the author of the software using the license. > > But an Open Source license should not be sabotaged by other legal > limitations (NDAs, patents, etc.). That should be pretty obvious from > reading the Open Source Definition (an "annotated" version also exists, > which includes "rationales": http://opensource.org/osd-annotated): > > "The program must include source code, and must allow distribution in > source code as well as compiled form. Where some form of a product is > not distributed with source code, there must be a well-publicized means > of obtaining the source code for no more than a reasonable reproduction > cost preferably, downloading via the Internet without charge. The source > code must be the preferred form in which a programmer would modify the > program. Deliberately obfuscated source code is not allowed. > Intermediate forms such as the output of a preprocessor or translator > are not allowed." How does the above language (which in any case is not in the Mozilla or Apache language) prevent sabotage by legal limitations such as patents? > > *** > > Take the MIT license as an example > http://opensource.org/licenses/MIT > > That is one of the shortest, most "liberal" licenses one can find. But > when a company uses it to deliver source code to a customer or client > while at the same time preventing the disclosure of the source code to > others, then at least the spirit of Open Source is broken. In such a > case it is not the Open Source license which is dominating the legal > situation but the other limitations. > > The issue here seems to be if it is ok to create a "standard" knowing > that there are conditions/limitations which make it impossible for an > "Open Source" project to distribute the source code. Again: that first > of all is not a legal issue, but it might be one, for example if the > problems created for Open Source projects are used in practice by a > vendor or vendors of proprietary software against Open Source alternatives. > > Cheers, > Andreas
Received on Wednesday, 5 June 2013 14:04:17 UTC