Re: [Libreoffice] LibreOffice licensing
- Original Message From: Jesús Corrius je...@softcatala.org To: michael.me...@novell.com Hi Michael, On Sat, Jun 4, 2011 at 6:11 PM, Michael Meeks michael.me...@novell.com wrote: On Sat, 2011-06-04 at 08:48 -0400, Allen Pulsifer wrote: 1. TDF takes OOo under the Apache License and combines it with LO contributions under the LGPL/MPL and licenses the combined work (LibreOffice) under both the LGPL and MPL? So if we say MPLv2 and LGPLv3+ - that is fine; and the resulting code would be under those (compatible) licenses. Which are copy-left. 2. A third party takes OOo under the Apache License and combines it with LO contributions under the MPL and proprietary closed-source code of its own to create a proprietary closed-source product? If they have changed the MPL code modules - they need to release those changes; otherwise (since the MPL is a weak-copy-left) they can not release other changes (like extensions) they bundle - obviously. That would not however stop third parties from combining the Apache OpenOffice code with LibreOffice code and doing with that whatever both licenses allowed. Sure - one example is IBM, they have a load of MPL code, and even LGPL code in Lotus Symphony. Amusingly, IBM are far more pragmatic in practise than ASF is - one of the tragic ironies of the situation. I guess it would be useful to create a wiki page with a FAQ about these license topics :) Just remember, that even with LGPL/GPL the changes _do not have to be contributed back to the community_; only made available to the customers of that product upon request (per LGPL, GPL and MPL). IOW, TDF may not necessarily get the contribution. It's just like any downstream project - they can modify it and don't necessarily have to contribute those modifications back to the upstream project. Sure, it works best when they do as everyone benefits, but they are not _required_ to do so. I only mention this, as it is often overlooked - and in comments like the above - by Meeks and others - they seem to forget that aspect about Copy-Left, LGPL/GPL/MPL. So yes, someone could take LO code directly, make a downstream, proprietary product and sell it - and they only have to make the code to that proprietary version (whether it is identical to the LO version or modified) to those who have purchased their proprietary product. (MPL says for 12 months; FSF recommends per GPL/LGPL 3 years). My point being that Allen is 100% correct, and copy-left does not prevent the situation you all seem to be so concerned about. Remember, Copy-Left is about the End-User, not the Developer. $0.02 Ben ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] LibreOffice licensing
- Original Message From: Kohei Yoshida kyosh...@novell.com To: BRM bm_witn...@yahoo.com Cc: libreoffice@lists.freedesktop.org Sent: Mon, June 6, 2011 11:44:37 AM Subject: Re: [Libreoffice] LibreOffice licensing On Mon, 2011-06-06 at 07:39 -0700, BRM wrote: Just remember, that even with LGPL/GPL the changes _do not have to be contributed back to the community_; only made available to the customers of that product upon request (per LGPL, GPL and MPL). Not entirely correct. The source has to be made available to the legal recipients of the binary. Whether or not they are customers is irrelevant in this context. When dealing with a proprietary product, they are one-in-the-same, however they present the EULA. IOW, TDF may not necessarily get the contribution. It's just like any downstream project - they can modify it and don't necessarily have to contribute those modifications back to the upstream project. Sure. But we can certainly ask for the source if we are interested, and they are obligated to provide it if we have (legally) received the binary, under the same license as the original source code. This is a very important point. As you pointed out - only if you have a _legal_ right to ask. That won't likely be the case though unless you are their customer. Yes, they can't prevent you from distributing the GPL/LGPL/MPL portion of the work; but they could prevent you from distributing their additions to the degree that the MPL/GPL/LGPL derivative work restrictions apply, if at all. Sure, it works best when they do as everyone benefits, but they are not _required_ to do so. I wouldn't put it that way. It works better for the downstream maintainers if they upstream their work, to make it easier to maintain their own modifications. If they think the benefit outweighs the cost of upstreaming, then they have every right not to upstream their changes. I only mention this, as it is often overlooked - and in comments like the above - by Meeks and others - they seem to forget that aspect about Copy-Left, LGPL/GPL/MPL. I don't think it is overlooked, but is already implied. Overlooked b/c of the nature of the statement. Your next response goes to show it... (MPL says for 12 months; FSF recommends per GPL/LGPL 3 years). This I didn't know. Good to know. Most on FLOSS don't - or don't realize it. But if you stopped and read the license it would become obvious - especially in the MPL case, didn't take me long to find section 3.2, or section 6 of the GPLv3 (specifically 6.d, a-c refer to distributing the object code/binary while 6d covers the source requirement). And, FYI, it doesn't have to be public - it could be behind an access protected service, or simply a write them and let them know you want a CD kind of thing - or even for free. So yes, one could start a company, make a derivative of LO. Offer it for sale; even make modifications, etc. and the only recipients of the changes would be said customers of the proprietary version. Further, they only necessarily have to get the source if they request it in some form, which may or may not happen during the required time period. (There is no requirement in either license beyond the required time period.) So, for example, a customer buys a copy from said company. After 4 years, they find a bug they want fixed, but the company only produced the one version. The customer is then out-of-luck with any ability to gain access to the source - the company is under no obligation to do so. Now suppose the company went out of business 2 years after the sale, they must then setup a means for 1 year by which customers can get the source (supposing Bankruptcy Court/etc allow the estate to meet the requirement). But if they went out of business 3 years and 1 day after the sale then again, there is no further obligation. My point being that Allen is 100% correct, and copy-left does not prevent the situation you all seem to be so concerned about. Remember, Copy-Left is about the End-User, not the Developer. In the context where copy-left licenses such as GPL/LGPL are used, the end users sometimes (or many times) equal developers. Surely the majority of end users of consumer applications who are not developers or servicers of those apps don't really care about the availability of the source code, though they may care more about the availability of the binaries. They may want to have the source available in case they need to hire consultancies to service the software after the purchase (or download), but even in those cases the direct beneficiaries of the copy-left licenses (often referred to as users in some context) are developers who end up servicing the app for the users of the binary. Only if the end-user obtains the source to provide to the developer. The developer may not necessarily
Re: [Libreoffice] FYI: Latest Oracle move wrt to OpenOffice.org
Original Message From: Norbert Thiebaud nthieb...@gmail.com Oracle announce: http://www.marketwire.com/press-release/statements-on-openofficeorg-contribution-to-apache-nasdaq-orcl-1521400.htm m IBM is very happy to be able to continue Symphony without having to give code back... (they seems to rejoyce at being able to do selective GPL: i.e what is yours is mine... but what is mine is yours only for the peice I don't care about and would like you to maintain instead): http://www.edbrill.com/ebrill/edbrill.nsf/dx/openoffice-moving-to-apache-good-news-for-the-desktop-productivity-market t The new project at Apache strengthens IBM's ability to continue to offer our own distributions of productivity tools based on the OpenOffice code base and make our own contributions to reinforce the overall community. FYI - LGPL/GPL does not _require_ that code be contributed back to the _community_. Projects work best when that happens, but that is not a requirement. The _requirement_ is that the code be accessible to those that the project is being distributed to - e.g. end-users. In the case of IBM, a user of Symphony would have been able to ask for the code and IBM would have had to provide it per LGPL/GPL if that were the license. It does not mean that IBM would have had to contribute back to LibreOffice, OpenOffice, or anyone else. Ben ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] FYI: Latest Oracle move wrt to OpenOffice.org
- Original Message
From: Norbert Thiebaud nthieb...@gmail.com
To: BRM bm_witn...@yahoo.com
Cc: libreoffice@lists.freedesktop.org
Sent: Wed, June 1, 2011 4:07:23 PM
Subject: Re: [Libreoffice] FYI: Latest Oracle move wrt to OpenOffice.org
On Wed, Jun 1, 2011 at 2:37 PM, BRM bm_witn...@yahoo.com wrote:
Original Message
From: Norbert Thiebaud nthieb...@gmail.com
Oracle announce:
http://www.marketwire.com/press-release/statements-on-openofficeorg-contribution-to-apache-nasdaq-orcl-1521400.htm
m
m
IBM is very happy to be able to continue Symphony without having to
give code back... (they seems to rejoyce at being able to do selective
GPL: i.e what is yours is mine... but what is mine is yours only for
the peice I don't care about and would like you to maintain instead):
http://www.edbrill.com/ebrill/edbrill.nsf/dx/openoffice-moving-to-apache-good-news-for-the-desktop-productivity-market
t
t
The new project at Apache strengthens IBM's ability to continue to
offer our own distributions of productivity tools based on the
OpenOffice code base and make our own contributions to reinforce the
overall community.
FYI - LGPL/GPL does not _require_ that code be contributed back to the
_community_. Projects work best when that happens, but that is not a
requirement.
The _requirement_ is that the code be accessible to those that the project
is
being distributed to - e.g. end-users.
And with Apache License that requirement is gone...
WRT OOo, never said it was there. just correcting the mistaken belief that GPL
always means sharing code with everyone - it doesn't.
A belief all too common in the GPL world.
From: Michael Meeks michael.me...@novell.com
True - on the other hand, if millions of people have the right to get
the source code (a mass market product). If a copy-left license is used
- it means the cheapest way to do that is to provide the source to
everyone. If no (C) assignment is required, then those changes can
trivially be merged, of course that is the LibreOffice structure.
As I said, projects work best when code is contributed back.
That said, there are many successful projects that are not GPL or LGPL that
don't have that requirement with very flourishing communities - many lead by
ASF.
From: Norbert Thiebaud nthieb...@gmail.com
In the case of IBM, a user of Symphony would have been able to ask for the
code
and IBM would have had to provide it per LGPL/GPL if that were the license.
It does not mean that IBM would have had to contribute back to LibreOffice,
OpenOffice, or anyone else.
But that is _not_ the license, and with Apache License they would not
have to make it available at ALL to anybody... just as is the case
with their proprietary OO fork today.
Hence the Enthusiastic blog campaign that flourished from IBMers in
the minutes/hours following the public announcement of Oracle's intend
to dump OpenOffice.org in Apache's lap.
But that's fine, IBM is free to conduct their business they way they
want, as long as there is no doubt in anybody's mind that that latest
Oracle' move has nothing to do with 'unifying/strengthening the
'community', but everything to do with Oracle's contractual obligation
to IBM and IBM desire to continue their proprietary fork.
OpenOffice.org version 1.1.4 was dual licensed under both the GNU
Lesser General Public License and Sun's own SISSL, which allowed for
entities to change the code without releasing their changes.
Therefore, IBM does not have to release the source code of Symphony.
source: http://ibm-lotus-symphony.software.informer.com/wiki/
If anybody in unconvinced why copyright assignment or Apache-like
full-copyright-license-no-string-attached are evil the quote above
should settle that.
And there are useful benefits to both approaches. Personally I am typically
more
likely to go GPL;
that said, I am getting ready to spear head a small project - to be added to a
major project - that will need to be able to
allow the major project to do something similar - they have a dual licensing
system, with both commercial and GPL licenses,
and my employer makes use of the commercial license. We generally do not modify
the that project, so nothing to contribute back normally any how, but
the commercial license lets us build our (proprietary) products on top of that
major project, and my little project will be very useful to me at work - a
major
improvement over what is currently provided.
Just saying, there's more than one way to skin the cat (as the old saying
goes),
and there are multiple reason for choosing difference licensing methods,
many of which are very valid reasons - not all of which lead to GPL/LGPL.
Ben
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Rationale for replacing Java with anything but c++ (was Re: web based libre office)
- Original Message From: Thorsten Guenther thorsten.guent...@aposso.de Hi Michael, Am 28.01.2011 14:58, schrieb Michael Meeks: Almost certainly you want to get involved with the existing odf toolkit project: http://odftoolkit.org/ they have a new Java API that does this - though not using LibreOffice. No, they created a stand alone lib. Great for running headless in your appserver. I remember OOo was raped to do such things in the past. I want LO to, for example, create an invoice or report from some backends data and present it to the user for further editing. Some interaction with the user would be desirable, to let him select some additional Data or something. Why go through the effort of (i) scripting LO and (ii) enabling your application to do that, when you could simply just make a UI to (a) show the existing document to the user in a view mode (read-only), (b) get the specific data you need in your application, presenting controlled interfaces to do so, and (c) write the ODF document yourself? While it may seem easier to incorporate an existing product like LO to do the document editing for you; it is likely far easier to just do it yourself and use a tool like ODF Tool Kit to write the output document and load it for display - at the very least, showing the user the output document with any kind of program (LO, OOo, Symphony, Calligra, etc.) would be very easy to do without having to enhance any of them for scripting. $0.02 Ben ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
