Fellowship of FSFE fellowship@fsfeurope.org wrote:
- Matthew Garrett criticised Canonical's contributor agreement[19]. Other copyright assignment tools, such as FSFE's Fiduciary License Agreement[20] and the GNU Project's copyright assignment, enable developers to prevent their code from being used in non-free software. In contrast, Canonical's agreement explicitly states that the company may distribute people's contributions under non-free licenses. If you value software freedom, FSFE recommends you not to sign agreements which make it possible to distribute your code under non-free licenses.
Is this recommendation, the reasoning behind it and the process that led to it documented somewhere?
The recommendation seems to imply that people who prefer or don't object to non-viral free software licenses don't value software freedom.
Fabian
On 02/07/2014 02:58 PM, Fabian Keil wrote:
Fellowship of FSFE fellowship@fsfeurope.org wrote:
- Matthew Garrett criticised Canonical's contributor agreement[19]. Other copyright assignment tools, such as FSFE's Fiduciary License Agreement[20] and the GNU Project's copyright assignment, enable developers to prevent their code from being used in non-free software. In contrast, Canonical's agreement explicitly states that the company may distribute people's contributions under non-free licenses. If you value software freedom, FSFE recommends you not to sign agreements which make it possible to distribute your code under non-free licenses.
Is this recommendation, the reasoning behind it and the process that led to it documented somewhere?
The recommendation seems to imply that people who prefer or don't object to non-viral free software licenses don't value software freedom.
It does not, I think.
Whether you prefer to release your code under a copyleft or more permissive license while still retaining the copyright yourself is a completely different matter from when you sign off your copyright without any guarantee that your code won't be released under a proprietary license.
As far as I can see it's too completely different situations; it's the assignment that makes the difference.
On Friday 07 February 2014 15:17:39 Carsten Agger wrote:
The recommendation seems to imply that people who prefer or don't object to non-viral free software licenses don't value software freedom.
It does not, I think.
The original blog post[1] by Matthew Garret does not imply this. Yet, the last sentence of the summary does:
If you value software freedom, FSFE recommends you not to sign agreements which make it possible to distribute your code under non-free licenses.
While I do understand (and share) the Foundation's interest in ensuring permanent freedom of code, I think this sentence has unfortunate wording. If the first part of the sentence had been omitted, I would have no problems with it.
I think the example of Qt (also in the blog post's comments) shows the subtleties of the whole thing and helps to illustrate the point I'm trying to make:
- The CLA for the Qt project requires you to allow co-licensing the source under a proprietary license. - The owner of Qt may make the entire Qt project proprietary by first releasing it under a BSD license.
This CLA clearly makes it possible to distribute your code under non-free licenses. OTOH, the KDE-Qt agreement includes a clause that effectively prohibits the owner of Qt from making the project more closed.
I think it's totally ok for the FSFE to make a recommendation against contributing to the Qt project -- after all the foundation is trying to fight the status quo.
However, implying that anyone contributing to Qt does not value software freedom seems like a comical statement at best.
Johannes
+ 2014-02-07 Fri 16:05, Johannes Zarl jzarl@fsfe.org:
On Friday 07 February 2014 15:17:39 Carsten Agger wrote:
The recommendation seems to imply that people who prefer or don't object to non-viral free software licenses don't value software freedom.
It does not, I think.
The original blog post[1] by Matthew Garret does not imply this. Yet, the last sentence of the summary does:
If you value software freedom, FSFE recommends you not to sign agreements which make it possible to distribute your code under non-free licenses.
No it does not, unless you think that FSFE is here talking about "agreements" that also include software licenses. But that's actually wrong because you don't "sign" a software license. So, really, that sentence does *not* imply that FSFE says people who use liberal licenses like BSD do not value software freedom.
In case you misread the summary, which I think is good and does not imply what you think it does, let me re-state this clearly:
FSFE does not say that non-protective licenses are not valuable for software freedom; nowhere.
I think the example of Qt (also in the blog post's comments) shows the subtleties of the whole thing and helps to illustrate the point I'm trying to make:
- The CLA for the Qt project requires you to allow co-licensing the source
under a proprietary license.
- The owner of Qt may make the entire Qt project proprietary by first
releasing it under a BSD license.
You see, the problem with your example is that it's actually wrong.
In case 2, what is “the owner of QT”? You say BSD. So what you really want to say is: the licensee (the person who *receives* the software under the BSD license) can make the entire QT project proprietary, because the license is liberal about this.
But that's actually a *totally different* position than if you are the "owner" of QT, meaning, you are the one in control of who can do what.
These are two entirely different situations, and as been reported before: a BSD license and a CLA are two completely different legal means towards achieving two very different outcomes.
FSFE is criticising the second, not the first; and AFAICS from Garret's blog quotations, this is also the point of concern there, not the GPL.
I think it's totally ok for the FSFE to make a recommendation against contributing to the Qt project -- after all the foundation is trying to fight the status quo.
However, implying that anyone contributing to Qt does not value software freedom seems like a comical statement at best.
Depends on what "to QT" means. To QT the free software project or to QT the company releasing proprietary software?
I think it's fair to assume that contributing to proprietary software (and *not* to free software) is not valuable to software freedom.
Any way: judging by the misunderstanding of the complex legal matter, I suppose an update to the newsletter with a footnote explaining that FSFE did *not* imply that liberal licenses are not valuable; so that even people who don't have a clue about the difference between copyright licensing and assignments cannot misunderstand.
On Monday 10 February 2014 13:52:11 Hugo Roy wrote:
- 2014-02-07 Fri 16:05, Johannes Zarl jzarl@fsfe.org:
On Friday 07 February 2014 15:17:39 Carsten Agger wrote:
The recommendation seems to imply that people who prefer or don't object to non-viral free software licenses don't value software freedom.
It does not, I think.
The original blog post[1] by Matthew Garret does not imply this. Yet, the last> sentence of the summary does:
If you value software freedom, FSFE recommends you not to sign agreements which make it possible to distribute your code under non-free licenses.
No it does not, unless you think that FSFE is here talking about "agreements" that also include software licenses.
I think we are talking about CLAs, not software licenses.
Let me make my thoughts more explicit (keeping the Qt example from my mail from Friday):
Person A wants to contribute to the Qt project, and signs the CLA that allows Digia to have a dual-licensing with both GPL and their proprietary license. Therefore the CLA makes it possible to distribute the code under non-free licenses. Therefore person A can not value software freedom.
But that's actually wrong because you don't "sign" a software license. So, really, that sentence does *not* imply that FSFE says people who use liberal licenses like BSD do not value software freedom.
Actually, I agree with you there, but when I first read the Carsten's sentence, I (mis?)read it as "The recommendation seems to imply that people who don't object to [allowing] *non-free* software licenses [on their code] don't value software freedom" or something like that.
I guess I was preoccupied since I already was unhappy with that last sentence of the summary. I'm sorry I did not read Carsten's sentence properly.
In case you misread the summary, which I think is good and does not imply what you think it does, let me re-state this clearly:
The summary (minus the last sentence) is good. I still think that last sentence has unfortunate wording. I hope I made my issues clear with the "Person A..." example above.
While the wording is, well, unfortunate, I did not want to express a general problem in the summary or the newsletter. I do enjoy reading it and appreciate the work that undoubtedly goes into it. The fact that we are disputing *one* sentence within the last half year or so that I'm on this list shows that the editors are *very* careful with writing the newsletter.
FSFE does not say that non-protective licenses are not valuable for software freedom; nowhere.
Good. That was also my expression. That's one reason why I wholeheartedly support the FSFE.
I think the example of Qt (also in the blog post's comments) shows the subtleties of the whole thing and helps to illustrate the point I'm trying to make:
- The CLA for the Qt project requires you to allow co-licensing the source
under a proprietary license.
- The owner of Qt may make the entire Qt project proprietary by first
releasing it under a BSD license.
You see, the problem with your example is that it's actually wrong.
How so?
In case 2, what is “the owner of QT”? You say BSD.
BSD is not a legal person, and thus cannot own anything. The owner (no quotes) is currently Digia, and was Nokia before that, and originally Trolltech. Since the agreement is binding to whoever buys the rights to Qt next, I thought it makes sense to refer not to Digia, but to the owner.
So what you really want to say is: the licensee (the person who *receives* the software under the BSD license) can make the entire QT project proprietary, because the license is liberal about this.
No, I did not say this. (Currently) *Digia* can make the Qt project proprietary, but would in the process be required to license all code under a BSD license.
I'm boldly assuming that you did not read the comments regarding the use of a CLA within the context of the Qt project on the summarised blog entry. I'm therefore ignoring most of the rest of the mail.
Depends on what "to QT" means. To QT the free software project or to QT the company releasing proprietary software?
Qt is the Qt project. There is no "QT the company".
I think it's fair to assume that contributing to proprietary software (and *not* to free software) is not valuable to software freedom.
Well, that stands to question here. Qt is arguably both proprietary *and* free software. Your sentence is certainly true for the general case, but Qt is a corner case. Does the (additional) contribution to proprietary software *weaken* the value of the contribution to the free software?
Cheers, Johannes
Dear Johannes,
It's not really helpful if you don't try to read replies to your post and focus on details like how the QT company is named (Diga or whatever, naming it the QT company is, I believe, enough to understand for anyone).
+ 2014-02-10 Mon 20:27, Johannes Zarl jzarl@fsfe.org:
On Monday 10 February 2014 13:52:11 Hugo Roy wrote:
No it does not, unless you think that FSFE is here talking about "agreements" that also include software licenses.
I think we are talking about CLAs, not software licenses.
Yes, but other posts were confused about this, hence the need to restate it again to avoid confusion.
Let me make my thoughts more explicit (keeping the Qt example from my mail from Friday):
Person A wants to contribute to the Qt project, and signs the CLA that allows Digia to have a dual-licensing with both GPL and their proprietary license. Therefore the CLA makes it possible to distribute the code under non-free licenses. Therefore person A can not value software freedom.
If person A values software freedom, he or she should contribute to QT, the software project (under the free software license: GPL or BSD whatever) but should not contribute to a scheme whereby the contribution would be proprietary software (or put somebody in a position to make that decision).
the work that undoubtedly goes into it. The fact that we are disputing *one* sentence within the last half year or so that I'm on this list shows that the editors are *very* careful with writing the newsletter.
Yes. And in this case, this bit was also given feedback from FSFE's legal team. However, it's easy to forget that many legal tools and concepts we deal with are not known to other people. Believe me, the whole thread starts from there.
- The owner of Qt may make the entire Qt project proprietary by first
releasing it under a BSD license.
You see, the problem with your example is that it's actually wrong.
How so?
I explained it to you in my former email.
To put it bluntly, your sentence is nonsense.
Let me take it bit by bit.
The owner of QT:
As I said earlier, it's not clear what you mean here. If I follow common understanding, the "owner" would be the copyright holder of QT software.
… may make the entire QT project proprietary by first releasing it under a BSD license
This sentence does not make sense. The copyright holder of QT has, under copyright law, all the right to release QT as proprietary software. There's no need to license to BSD first, or to anything.
As I wrote, what you really wanted to say is not "owner" but "licensee", otherwise there's no point in mentioning the BSD license in your sentence.
In case 2, what is “the owner of QT”? You say BSD.
BSD is not a legal person, and thus cannot own anything. The owner (no quotes)
Of course I meant the BSD license here. What else would I be talking about?!
As already said: the whole thing looks like a basic misunderstanding of what the person is in a legal position to do. The owner and the licensee are in two very different positions.
This is why software copyright licenses are an entirely different beast than software copyright assignments.
I think it's fair to assume that contributing to proprietary software (and *not* to free software) is not valuable to software freedom.
Well, that stands to question here. Qt is arguably both proprietary *and* free software. Your sentence is certainly true for the general case, but Qt is a corner case. Does the (additional) contribution to proprietary software *weaken* the value of the contribution to the free software?
My personal opinion here is that a business model built around making money with proprietary software, and contributing to that business model, is not really valuable to software freedom indeed.
+ 2014-02-11 Tue 00:05, Hugo Roy hugo@fsfe.org:
I think it's fair to assume that contributing to proprietary software (and *not* to free software) is not valuable to software freedom.
Well, that stands to question here. Qt is arguably both proprietary *and* free software. Your sentence is certainly true for the general case, but Qt is a corner case. Does the (additional) contribution to proprietary software *weaken* the value of the contribution to the free software?
My personal opinion here is that a business model built around making money with proprietary software, and contributing to that business model, is not really valuable to software freedom indeed.
Just to avoid confusion, I'm speaking generally here. I do not care about the particular Qt situation and I'm not making any judgment on that case.
Dear Hugo,
On Tuesday 11 February 2014 00:05:02 Hugo Roy wrote:
It's not really helpful if you don't try to read replies to your post and focus on details like how the QT company is named (Diga or whatever, naming it the QT company is, I believe, enough to understand for anyone).
I did read your reply to my first email. I also replied to it step-by-step up to the point where you assumptions as to what I had meant in my first mail and what I had actually written in my first mail deviated so far as to where there was no common ground anymore.
I did mention that part about Qt not being a company, but being owned by Digia because of the previous statement of you citing "BSD" as the "owner" of the Qt project.
Person A wants to contribute to the Qt project, and signs the CLA that allows Digia to have a dual-licensing with both GPL and their proprietary license. Therefore the CLA makes it possible to distribute the code under non-free licenses. Therefore person A can not value software freedom.
If person A values software freedom, he or she should contribute to QT, the software project (under the free software license: GPL or BSD whatever) but should not contribute to a scheme whereby the contribution would be proprietary software (or put somebody in a position to make that decision).
Ok, then the implication in that last sentence of the summary seems to have been deliberate in its wording. Thanks for the info.
- The owner of Qt may make the entire Qt project proprietary by first
releasing it under a BSD license.
You see, the problem with your example is that it's actually wrong.
How so?
I explained it to you in my former email.
To put it bluntly, your sentence is nonsense.
It is a one-sentence summary of the agreement between KDE and the owner/Digia/copyright holder/"Qt"/whatever. It is nonsense if one redefines the meaning of owner and ignores the references to the blog post comments and has been oblivious to the way KDE and "Qt" are working together.
Let me take it bit by bit.
The owner of QT:As I said earlier, it's not clear what you mean here. If I follow common understanding, the "owner" would be the copyright holder of QT software.
What other than common understanding should I have followed in communication? Yes, as I have written before, I do mean Digia, which is the copyright holder.
… may make the entire QT project proprietary by first releasing it under a BSD licenseThis sentence does not make sense. The copyright holder of QT has, under copyright law, all the right to release QT as proprietary software. There's no need to license to BSD first, or to anything.
That's why there has been an additional agreement between the "KDE Free Qt Foundation" and Trolltech (and later on Nokia, and now Digia) that added this requirement. I have written that before, but you seem to have skipped it. If you still don't want to go to the comments section on the linked blog entry, here's a writeup of that agreement:
http://www.kde.org/community/whatiskde/kdefreeqtfoundation.php
As I wrote, what you really wanted to say is not "owner" but "licensee", otherwise there's no point in mentioning the BSD license in your sentence.
No, the licensees of the Qt library (and I guess other products under the Qt label) can only license Qt according to the GPL (or the proprietary license should they want to do that).
The owner and the licensee are in two very different positions.
Well, yes.
This is why software copyright licenses are an entirely different beast than software copyright assignments.
Also, yes.
I think it's fair to assume that contributing to proprietary software (and *not* to free software) is not valuable to software freedom.
Well, that stands to question here. Qt is arguably both proprietary *and* free software. Your sentence is certainly true for the general case, but Qt is a corner case. Does the (additional) contribution to proprietary software *weaken* the value of the contribution to the free software?
My personal opinion here is that a business model built around making money with proprietary software, and contributing to that business model, is not really valuable to software freedom indeed.
I can live with that. I'm not yet sure about how I'd answer the question myself, though.
Johannes
P.S.: I will refrain to posting another reply to this thread. I *do* think that my mails were not totally incomprehensible or devoid of logic. My lack of further participation shall not mean that I do not read or value your reply should you write one.
+ 2014-02-11 Tue 01:03, Johannes Zarl jzarl@fsfe.org:
I did mention that part about Qt not being a company, but being owned by Digia because of the previous statement of you citing "BSD" as the "owner" of the Qt project.
What? Why would "BSD" mean any other thing than the BSD license here? I already explained in the last email!
- The owner of Qt may make the entire Qt project proprietary by first
releasing it under a BSD license.
You see, the problem with your example is that it's actually wrong.
How so?
I explained it to you in my former email.
To put it bluntly, your sentence is nonsense.
It is a one-sentence summary of the agreement between KDE and the owner/Digia/copyright holder/"Qt"/whatever.
It is nonsense if one redefines the meaning of owner and ignores the references to the blog post comments and has been oblivious to the way KDE and "Qt" are working together.
We were speaking in general terms, and suddenly you're talking about a specific case. I was never commenting on the specific case and only said "Qt" as an example to try to explain to you why what you wrote **in general terms** was wrong.
I'm sorry to tell you that what you're writing there does not make sense to me. I don't know how to explain it in another manner and I don't understand what you're writing now.
You say "it is nonsense if one redefines the meaning of owner" but that's actually the **opposite** of what I said. If you take the common understanding of what "owner" would mean in your sentence, it would be the copyright holder (and you seem to agree with that common understanding). But in that case the sentence does not make sense because the copyright holder can always make something proprietary, there's no impact from the BSD (LICENSE!) or whatsoever.
What I'm only trying to do here is to make sure that people in FSFE lists can understand some of the various implications that different legal tools have. This is why we criticised some types of copyright assignments in our newsletter. Because I've seen myself at FOSDEM this year that it's far from clear to many developers what copyright licenses, copyright assignments and things like the FLA are. And I agree it's easy to get lost when you don't understand them. It took some time to make sure that people understood broadly what the GPL did exactly (and it's still far from finished but at least 95% is done and that's enough); then again it took time to understand software patents and how they are negative; now have to make sure people understand these copyright assignments before they can make a conscious decision about whether they think this is good for software freedom or not.
Oh BTW, since you were talking about KDE, KDE has adopted FSFE's FLA years ago: http://ev.kde.org/rules/fla.php
Best,
Hi all,
On Tue, Feb 11, 2014 at 1:03 AM, Johannes Zarl jzarl@fsfe.org wrote:
Dear Hugo,
On Tuesday 11 February 2014 00:05:02 Hugo Roy wrote:
It's not really helpful if you don't try to read replies to your post and focus on details like how the QT company is named (Diga or whatever, naming it the QT company is, I believe, enough to understand for anyone).
I did read your reply to my first email. I also replied to it step-by-step up to the point where you assumptions as to what I had meant in my first mail and what I had actually written in my first mail deviated so far as to where there was no common ground anymore.
I did mention that part about Qt not being a company, but being owned by Digia because of the previous statement of you citing "BSD" as the "owner" of the Qt project.
Just to clarify: Qt does not "belong" to Digia, they only have rights to distribute it under various licenses, e.g. if you want to purchase Qt you go to Digia, but that doesn't mean they own it. The Qt Project is licensed under multiple licenses exactly to avoid it being the sole property of a company.
Regards, Myriam
* Johannes Zarl:
Let me make my thoughts more explicit (keeping the Qt example from my mail from Friday):
Person A wants to contribute to the Qt project, and signs the CLA that allows Digia to have a dual-licensing with both GPL and their proprietary license. Therefore the CLA makes it possible to distribute the code under non-free licenses. Therefore person A can not value software freedom.
Or the person is not aware what the CLA implies, or disagrees about the impact of those implications.
This is a complicated topic. I don't understand why the FSFE is against CLAs, considering that it granted permissions to use FLA code in proprietary programs (see the previous discussion about the agreement with Bacula Systems—the published agreement is not even restricted to Bacula code).
On 15/02/14 18:06, Florian Weimer wrote:
- Johannes Zarl:
Let me make my thoughts more explicit (keeping the Qt example from my mail from Friday):
Person A wants to contribute to the Qt project, and signs the CLA that allows Digia to have a dual-licensing with both GPL and their proprietary license. Therefore the CLA makes it possible to distribute the code under non-free licenses. Therefore person A can not value software freedom.
Or the person is not aware what the CLA implies, or disagrees about the impact of those implications.
This is a complicated topic. I don't understand why the FSFE is against CLAs, considering that it granted permissions to use FLA code in proprietary programs (see the previous discussion about the agreement with Bacula Systems—the published agreement is not even restricted to Bacula code).
The worst CLAs are basically like employment agreements - but without a salary
There is a big difference between assigning copyright (or giving an unlimited license to sub-license) to a company and giving those rights to a democratically managed non-profit organisation like FSF(E).
There are always going to be a subset of developers who will never sign a CLA to a third-party corporation. As a consequence, those projects with corporate CLAs are always going to be at a disadvantage.
On 15/02/14 17:06, Florian Weimer wrote:
This is a complicated topic. I don't understand why the FSFE is against CLAs, considering that it granted permissions to use FLA code in proprietary programs (see the previous discussion about the agreement with Bacula Systems—the published agreement is not even restricted to Bacula code).
This is indeed a complicated topic. FSFE is not against CLAs in general, but some (like Canonical's) in particular.
The resolution of the Bacula systems was the least of many evils. We are not particularly happy about the outcome in this case, but the choices were not all that great to begin with.
Matija, would you please explain this in greater detail to our Fellows and other discussants? Thanks.
Cheers,
Hullo,
first of all I’m sorry for the late reply. I was battling with a persistent flu for two weeks now.
Die 16. 02. 14 et hora 00:24:46 Heiki Repentinus Ojasild scripsit:
On 15/02/14 17:06, Florian Weimer wrote:
This is a complicated topic. I don't understand why the FSFE is against CLAs, considering that it granted permissions to use FLA code in proprietary programs (see the previous discussion about the agreement with Bacula Systems—the published agreement is not even restricted to Bacula code).
This is indeed a complicated topic. FSFE is not against CLAs in general, but some (like Canonical's) in particular.
The issue is bigger with CA [Copyright Assignments], because the contributors assign *all* their rights to the entity and often retain (actually get assigned back) very little power over their own work. That is exactly why we wrote the FLA [Fiduciary License Agreement] – to create a balance between the entity/copyright holder and the contributors.
This is clearly stated in FLA’s text itself, but if there is any clarification needed, *please do let me know* , so we can improve the text in the future version.
I’ve also given a lightning talk on how FLA works on:
https://conf.kde.org/en/Akademy2013/public/events/75 http://mirrors.fe.up.pt/kde-applicationdata/akademy/2013/videos/Lightning_Ta...
Going back to the question of CLA – as Heiki mentioned, we don’t have an issue with them in general, as they are usually just about which license your work will be released under.
The resolution of the Bacula systems was the least of many evils. We are not particularly happy about the outcome in this case, but the choices were not all that great to begin with.
Exactly. The only reason why Bacula is able to pull off the proprietary version is that parallel to the FLA assigning the right to FSFE, all the contributors also signed a CA to Kern. The FLA does give the contributors (“beneficiaries” in the FLA text) the right to release their own work under *any* license, even proprietary. That is a concious decision, so contributors do not lose any rights when signing the FLA. Since the developers agreed in the CA with having their work included in a proprietary version, there is nothing we can do about it. What we did negotiate though is to have all the fixes and new features from the proprietary version released into the FS community version in due time.
Bacula was also mentioned in the following FLA talk at FOSDEM, if that is of help:
https://fosdem.org/2014/schedule/event/fla/ http://video.fosdem.org/2014/H2213/Saturday/Fiduciary_License_Agreement.webm
cheers, Matija
* Matija Šuklje:
Exactly. The only reason why Bacula is able to pull off the proprietary version is that parallel to the FLA assigning the right to FSFE, all the contributors also signed a CA to Kern.
Please point out where in the FSFE/Bacula Systems agreement the license grant under B(1) is restricted to Bacula code.
The only reason why Bacula is able to pull off the proprietary version is that parallel to the FLA assigning the right to FSFE, all the contributors also signed a CA to Kern.
I expect that most "Beneficiaries" who have signed FLAs with FSFE would be rather surprised that "Bacula Systems S.A. respectively Kern Sibbald has the right to use, reproduce, modify, redistribute and make available software based on [their] contributions and resulting software 'under other licenses' including under a proprietary license as the Bacula Enterprise Version, in accordance with Section 3 (2) of the FLA.".
On 03/10/2014 10:10 AM, Florian Weimer wrote:
Exactly. The only reason why Bacula is able to pull off the proprietary version is that parallel to the FLA assigning the right to FSFE, all the contributors also signed a CA to Kern.
Please point out where in the FSFE/Bacula Systems agreement the license grant under B(1) is restricted to Bacula code.
The only reason why Bacula is able to pull off the proprietary version is that parallel to the FLA assigning the right to FSFE, all the contributors also signed a CA to Kern.
I expect that most "Beneficiaries" who have signed FLAs with FSFE would be rather surprised that "Bacula Systems S.A. respectively Kern Sibbald has the right to use, reproduce, modify, redistribute and make available software based on [their] contributions and resulting software 'under other licenses' including under a proprietary license as the Bacula Enterprise Version, in accordance with Section 3 (2) of the FLA.".
Section B 1. cannot be interpreted without regard to the surrounding clauses. Section A and the preamble of Section B make it clear that the agreement concerns the Bacula software.
Die 10. 03. 14 et hora 11:10:23 Florian Weimer scripsit:
The only reason why Bacula is able to pull off the proprietary version is that parallel to the FLA assigning the right to FSFE, all the contributors also signed a CA to Kern.
I expect that most "Beneficiaries" who have signed FLAs with FSFE would be rather surprised that "Bacula Systems S.A. respectively Kern Sibbald has the right to use, reproduce, modify, redistribute and make available software based on [their] contributions and resulting software 'under other licenses' including under a proprietary license as the Bacula Enterprise Version, in accordance with Section 3 (2) of the FLA.".
As already stated. He’s able to do that because these people have also signed a separate Copyright Assignment with which they assigned their copyright to directly to Kern.
Please do not confuse the FLA that people have signed with FSFE and the CA that they signed with Kern (that happens to bear the name “FLA”).
Rest assured we’re working hard on fixing this situation.
If you have any internal information I should be aware of, please do let me know.
cheers, Matija
+ 2014-02-15 Sat 18:06, Florian Weimer fw@deneb.enyo.de:
This is a complicated topic. I don't understand why the FSFE is against CLAs, considering that it granted permissions to use FLA code in proprietary programs (see the previous discussion about the agreement with Bacula Systems—the published agreement is not even restricted to Bacula code).
FSFE never *granted* permissions to use FLA-covered code in proprietary programs. It simply does not have that power under the FLA.
The text of the FLA is available to read here http://fsfe.org/activities/ftf/fla.html
It's not that long, please have a look.
Some background on the Bacula case is available here https://fsfe.org/activities/ftf/bacula-agreement.en.html
The bit that contradicts directly what you are saying is:
FSFE does not endorse the existence of a non-free version, but FSFE cannot forbid authors to execute the rights granted by copyright in their own work, as long as this does not limit the scope of fiduciary's exclusive license.
The permission to make proprietary software was absolutely not granted by FSFE, but directly by developers (who hold copyright in their contributions).
* Hugo Roy:
Some background on the Bacula case is available here https://fsfe.org/activities/ftf/bacula-agreement.en.html
The bit that contradicts directly what you are saying is:
FSFE does not endorse the existence of a non-free version, but FSFE cannot forbid authors to execute the rights granted by copyright in their own work, as long as this does not limit the scope of fiduciary's exclusive license.
The web page has markedly different content from the PDF file. You need to read the latter and check what software is covered.
The permission to make proprietary software was absolutely not granted by FSFE, but directly by developers (who hold copyright in their contributions).
The wording in the agreement does not restrict its scope to Bacula code that had already been licensed to Bacula Systems by its authors.
+ 2014-02-18 Tue 22:30, Florian Weimer fw@deneb.enyo.de:
The bit that contradicts directly what you are saying is:
FSFE does not endorse the existence of a non-free version, but FSFE cannot forbid authors to execute the rights granted by copyright in their own work, as long as this does not limit the scope of fiduciary's exclusive license.The web page has markedly different content from the PDF file. You need to read the latter and check what software is covered.
What is different exactly? Are you implying that the statement above is not true? Please give arguments and reasonings instead of simply implying such things.
You wrote earlier that FSFE granted permission for proprietary software. That is simply untrue and if you believe otherwise, you did not understand the Bacula agreement, or you did not not understand what’s in FSFE’s legal power as a fiduciary under the FLA.
The permission to make proprietary software was absolutely not granted by FSFE, but directly by developers (who hold copyright in their contributions).
The wording in the agreement does not restrict its scope to Bacula code that had already been licensed to Bacula Systems by its authors.
The agreement aims at resolving a lot of issues because it was a messy situation involving multiple agreements in several steps over the years; that does not mean that FSFE endorses proprietary software. I stand by what I wrote: the permission to make proprietary software was not granted by FSFE.
Please be more explicit in your response instead of just making vague accusations that FSFE endorses proprietary software. Thanks.
+ 2014-02-07 Fri 14:58, Fabian Keil freebsd-listen@fabiankeil.de:
Fellowship of FSFE fellowship@fsfeurope.org wrote:
- Matthew Garrett criticised Canonical's contributor agreement[19]. Other copyright assignment tools, such as FSFE's Fiduciary License Agreement[20] and the GNU Project's copyright assignment, enable developers to prevent their code from being used in non-free software. In contrast, Canonical's agreement explicitly states that the company may distribute people's contributions under non-free licenses. If you value software freedom, FSFE recommends you not to sign agreements which make it possible to distribute your code under non-free licenses.
Is this recommendation, the reasoning behind it and the process that led to it documented somewhere?
The recommendation seems to imply that people who prefer or don't object to non-viral free software licenses don't value software freedom.
Hi Fabian,
First, there's no such thing as a “viral” free software license. This term does not mean anything legally, nor technically. It is simply Microsoft-propaganda from the 1990s. If you are looking for a more accurate term, simply state copyleft licenses, or if you don't like the term for its need to be defined you can use “hereditary” licenses, this is more accurate to what copyleft licenses actually do. You can also use the liberal/protective dichotomy which IMHO is quite accurate too.
Second, this is not about whether people prefer BSD/MIT-style licenses or (A/L)GPL-style. This is about assigning your copyright to an entity in a way that makes it possible for that entity to decide on their own if they want to release as proprietary software or not something that include your contribution. It may very well be possible that the whole is never released as Free Software at all, whether under a liberal license or under a protective license.
Third, to answer your question, this was discussed many times within FSFE, especially in the process that led to the FLA http://fsfe.org/activities/ftf/fla.html years ago.
As far as this bit in the newsletter goes, it was discussed including in FSFE's legal team.
In this area, the goal of FSFE is clear: management of copyright should always be done with Free Software in mind (whether BSD or GPL, it does not matter).
Hugo Roy hugo@fsfe.org wrote:
- 2014-02-07 Fri 14:58, Fabian Keil freebsd-listen@fabiankeil.de:
Fellowship of FSFE fellowship@fsfeurope.org wrote:
- Matthew Garrett criticised Canonical's contributor agreement[19]. Other copyright assignment tools, such as FSFE's Fiduciary License Agreement[20] and the GNU Project's copyright assignment, enable developers to prevent their code from being used in non-free software. In contrast, Canonical's agreement explicitly states that the company may distribute people's contributions under non-free licenses. If you value software freedom, FSFE recommends you not to sign agreements which make it possible to distribute your code under non-free licenses.
Is this recommendation, the reasoning behind it and the process that led to it documented somewhere?
The recommendation seems to imply that people who prefer or don't object to non-viral free software licenses don't value software freedom.
First, there's no such thing as a “viral” free software license.
You may not like the term, but this doesn't mean that it doesn't exist: http://en.wikipedia.org/wiki/Viral_license
Second, this is not about whether people prefer BSD/MIT-style licenses or (A/L)GPL-style. This is about assigning your copyright to an entity in a way that makes it possible for that entity to decide on their own if they want to release as proprietary software or not something that include your contribution.
This doesn't require copyright assignment, though. The same can and does happen with what you refer to as liberal licenses.
Assumingly a lot of free-software-valueing people are fine with this or they would have chosen different licenses.
It mayvery well be possible that the whole is never released as Free Software at all, whether under a liberal license or under a protective license.
Again, this doesn't require copyright assignment.
Even Matthew Garret only seems to be concerned about copyleft licenses (and how Canonical defends the CLA):
| ... Canonical ship software under the GPLv3 family of licenses | (GPL, AGPL and LGPL) but require that contributors sign an agreement | that permits Canonical to relicense their contributions under a | proprietary license. This is a fundamentally different situation | to almost all widely accepted CLAs, and it's disingenuous for | Canonical to defend their CLA by pointing out the broad community | uptake of, for instance, the Apache CLA. http://mjg59.dreamwidth.org/29160.html
Third, to answer your question, this was discussed many times within FSFE, especially in the process that led to the FLA http://fsfe.org/activities/ftf/fla.html years ago.
As far as this bit in the newsletter goes, it was discussed including in FSFE's legal team.
Is the discussion documented somewhere?
Fabian
+ 2014-02-09 Sun 16:04, Fabian Keil freebsd-listen@fabiankeil.de:
First, there's no such thing as a “viral” free software license.
You may not like the term, but this doesn't mean that it doesn't exist: http://en.wikipedia.org/wiki/Viral_license
It's not that I don't like the term. It's a term that is not accurate, but it's misguided, ill-informed and backed by FUD from Microsoft.
And you are right only on this: not liking the term does not mean it does not exist. But it's true the other way around: not liking it does not mean such a thing as a viral license exists either.
Now, have a look at the wikipedia article: it's of poor quality, it says: “This article relies on references to primary sources. Please add references to secondary or tertiary sources. (December 2011)” has a couple of "citation needed" and has a prominent section “Criticism of the term” taking almost 1/3 of the whole article. You cannot miss the fact that most references in this article are about Microsoft statement from early 2000s.
So you are actually making my point stronger:
Do not use this term, because you are not making yourself a favour by using this term, you are only discrediting what you are saying.
Second, this is not about whether people prefer BSD/MIT-style licenses or (A/L)GPL-style. This is about assigning your copyright to an entity in a way that makes it possible for that entity to decide on their own if they want to release as proprietary software or not something that include your contribution.
This doesn't require copyright assignment, though. The same can and does happen with what you refer to as liberal licenses.
Yes, and so? I don't understand your point. What we are talking about here is *copyright assignment*, nothing else.
It mayvery well be possible that the whole is never released as Free Software at all, whether under a liberal license or under a protective license.
Again, this doesn't require copyright assignment.
And so, what's your point?
Copyright assignments are done for other reasons. You are the one who were confused about this in your former email, I'm only making it clear that what we wrote in the newsletter has nothing to do with BSD licenses. It's an entirely different subject, which according to your first email was something you did not understand fully.
With a copyright assignment, the assigned entity owns the rights itself, it's an entirely different position than merely being a licensee.
Even Matthew Garret only seems to be concerned about copyleft licenses (and how Canonical defends the CLA):
| ... Canonical ship software under the GPLv3 family of licenses | (GPL, AGPL and LGPL) but require that contributors sign an agreement | that permits Canonical to relicense their contributions under a | proprietary license. This is a fundamentally different situation | to almost all widely accepted CLAs, and it's disingenuous for | Canonical to defend their CLA by pointing out the broad community | uptake of, for instance, the Apache CLA. http://mjg59.dreamwidth.org/29160.html
From the paragraph you're quoting, I can only state that you seem to have a complete misunderstanding about the subject.
You're saying that the above paragraph means that Garret is concerned about copyleft; whereas if you read the statement by Garret you will see that there's a sentence about copyleft, and then there's "*but*" about CLAs. The criticism is *not about copyleft*, it's about Canonical's CLA (copyright assignment).
Third, to answer your question, this was discussed many times within FSFE, especially in the process that led to the FLA http://fsfe.org/activities/ftf/fla.html years ago.
As far as this bit in the newsletter goes, it was discussed including in FSFE's legal team.
Is the discussion documented somewhere?
What do you mean “documented”? FSFE's position regarding proprietary software is well documented on fsfe.org and elsewhere. We don't have to document every single discussion that leads to the publication of 1 single paragraph anywhere. I have explained to you the historic background, which team¹ is in charge, and I have tried to explain to you some legal differences between a copyright assignment and a copyright license. I don't see what I can do further here.
Best, Hugo
1. The team in charge of legal issues in FSFE is mostly the legal team formerly known as the Freedom Task Force. We're a team of lawyers and experts in Free Software, some of us for longer than FSFE even exists.
+ 2014-02-09 Sun 19:23, Hugo Roy hugo@fsfe.org:
And you are right only on this: not liking the term does not mean it does not exist. But it's true the other way around: not liking it does not mean such a thing as a viral license exists either.
Obviously, I meant here that liking at term does not mean something exists either.
I like the term arfologic-unicorn.
Hugo Roy hugo@fsfe.org wrote:
- 2014-02-09 Sun 16:04, Fabian Keil freebsd-listen@fabiankeil.de:
First, there's no such thing as a “viral” free software license.
You may not like the term, but this doesn't mean that it doesn't exist: http://en.wikipedia.org/wiki/Viral_license
It's not that I don't like the term. It's a term that is not accurate, but it's misguided, ill-informed and backed by FUD from Microsoft.
And you are right only on this: not liking the term does not mean it does not exist. But it's true the other way around: not liking it does not mean such a thing as a viral license exists either.
Now, have a look at the wikipedia article: it's of poor quality, it says: “This article relies on references to primary sources. Please add references to secondary or tertiary sources. (December 2011)” has a couple of "citation needed" and has a prominent section “Criticism of the term” taking almost 1/3 of the whole article. You cannot miss the fact that most references in this article are about Microsoft statement from early 2000s.
So you are actually making my point stronger:
Do not use this term, because you are not making yourself a favour by using this term, you are only discrediting what you are saying.
I understand your point of view, but I don't share it.
Second, this is not about whether people prefer BSD/MIT-style licenses or (A/L)GPL-style. This is about assigning your copyright to an entity in a way that makes it possible for that entity to decide on their own if they want to release as proprietary software or not something that include your contribution.
This doesn't require copyright assignment, though. The same can and does happen with what you refer to as liberal licenses.
Yes, and so? I don't understand your point. What we are talking about here is *copyright assignment*, nothing else.
It mayvery well be possible that the whole is never released as Free Software at all, whether under a liberal license or under a protective license.
Again, this doesn't require copyright assignment.
And so, what's your point?
My point is that in case of permissive licenses the licensee is already free to reuse the software as part of a proprietary product and thus doesn't need copyright assignment.
Copyright assignments are done for other reasons. You are the one who were confused about this in your former email,
I actually understand and understood the differences between copyright assignments and licenses.
Even Matthew Garret only seems to be concerned about copyleft licenses (and how Canonical defends the CLA):
| ... Canonical ship software under the GPLv3 family of licenses | (GPL, AGPL and LGPL) but require that contributors sign an agreement | that permits Canonical to relicense their contributions under a | proprietary license. This is a fundamentally different situation | to almost all widely accepted CLAs, and it's disingenuous for | Canonical to defend their CLA by pointing out the broad community | uptake of, for instance, the Apache CLA. http://mjg59.dreamwidth.org/29160.html
From the paragraph you're quoting, I can only state that you seem to have a complete misunderstanding about the subject.
You're saying that the above paragraph means that Garret is concerned about copyleft; whereas if you read the statement by Garret you will see that there's a sentence about copyleft, and then there's "*but*" about CLAs. The criticism is *not about copyleft*, it's about Canonical's CLA (copyright assignment).
I agree that Garret is not criticising copyleft licenses.
He states that the CLA allows Canonical to use code in proprietary products and that this is a problem for software under copyleft licences (as they don't allow this already).
He does not state that this is a problem for free software in general (as liberal licenses already allow the reuse in proprietary products anyway).
Alas, the newsletter said:
| If you value software freedom, FSFE recommends you not to sign | agreements which make it possible to distribute your code under | non-free licenses.
It did not say:
| If you feel strongly about your copyleft code not being used in | proprietary products, FSFE recommends that you do not sign | agreements that make it possible to distribute your code under | non-free licenses.
The latter makes sense to me (even if it's somewhat obvious), while the former seems to imply that there's a conflict between valueing software freedom and allowing the reuse of code in proprietary products.
Fabian
On Wed, 2014-02-19 at 11:03 +0100, Fabian Keil wrote:
Hugo Roy hugo@fsfe.org wrote:
Second, this is not about whether people prefer BSD/MIT-style licenses or (A/L)GPL-style. This is about assigning your copyright to an entity in a way that makes it possible for that entity to decide on their own if they want to release as proprietary software or not something that include your contribution.
This doesn't require copyright assignment, though. The same can and does happen with what you refer to as liberal licenses.
Yes, and so? I don't understand your point. What we are talking about here is *copyright assignment*, nothing else.
It mayvery well be possible that the whole is never released as Free Software at all, whether under a liberal license or under a protective license.
Again, this doesn't require copyright assignment.
And so, what's your point?
My point is that in case of permissive licenses the licensee is already free to reuse the software as part of a proprietary product and thus doesn't need copyright assignment.
It does if you want to re-license the whole product (without asking the contributors) or even worse turn it to proprietary.
~nikos
+ 2014-02-19 Wed 11:03, Fabian Keil freebsd-listen@fabiankeil.de:
My point is that in case of permissive licenses the licensee is already free to reuse the software as part of a proprietary product and thus doesn't need copyright assignment.
Copyright assignments are done for other reasons.
You really really underestimate the power that copyright assignments give to the assignee. The assignee is much more powerful than a mere licensee (for instance, to sue for infringement).