FSF and SFC work with Canonical on an "intellectual property" policy update
FSF and SFC work with Canonical on an "intellectual property" policy update
Posted Jul 15, 2015 16:51 UTC (Wed) by Jonimus (subscriber, #89694)Parent article: FSF and SFC work with Canonical on an "intellectual property" policy update
Posted Jul 15, 2015 17:05 UTC (Wed)
by ewan (guest, #5533)
[Link] (31 responses)
Posted Jul 15, 2015 20:18 UTC (Wed)
by jospoortvliet (guest, #33164)
[Link] (30 responses)
Posted Jul 15, 2015 21:01 UTC (Wed)
by stumbles (guest, #8796)
[Link]
Posted Jul 16, 2015 10:33 UTC (Thu)
by jriddell (subscriber, #3916)
[Link] (28 responses)
Posted Jul 16, 2015 18:10 UTC (Thu)
by rahvin (guest, #16953)
[Link] (27 responses)
Though it does provide further evidence that they don't want to be a member of the community and anything they do needs to be watched like a hawk for further violations. I think it's ample evidence that projects like kubuntu should re-base on Debian.
Posted Jul 16, 2015 18:55 UTC (Thu)
by jspaleta (subscriber, #50639)
[Link] (26 responses)
Canonical doesn't have to have actively threatened in the past for this to be a real problem for companies moving forward. A lack of past enforcement does not defend anyone in the future when it comes to copyright issues. Canonical can pick and choose who to go after at any point.
The ambiguity of the IP policy is itself a long term liability for anyone making use of the Ubuntu binaries to spin up a derivative. The fact that the IP policy _allows_ Canonical to do a lot of nefarious things in a grey area of common uses of the Ubuntu binaries is the entire point. The fact that Canonical chooses to refrain from doing those things right now... just muddles the waters a bit and gives people false sense of security. Trust but verify.
The world ending nuclear scenario here is Canonical gets bought out and the new management team takes a look at the IP Policy and no longer feels the same ethical or moral restrain with regard to making full use of its IP policy compliance options. This is a realistic future scenario and past restraint on Canonical's part now is not codified in a way that could be used as an estoppel defense in court. The Ubuntu repository licensing policy for main and restricted might provide estoppel but really who in the hell wants to test that? Any company with any competence on IP issues will look at that policy and just avoid it entirely. Cough... Valve... cough.
The good faith uses that do not require an explicit license need to be codified. The uses that require a license need to be codified. If you are thinking about using any non-GPL Ubuntu project binaries in a way that is not clearly codified in the IP policy, then you should contact Canonical legal about your intended usage, and when they fail to give you a determination as to whether or not you need a license in a timely manner, and they will, you then go choose another option to rebase from. How much of the plumbing under say KDE is actually non-(L)GPL...and is impacted by the IP policy as it currently stands? Xorg is just one piece. What else would need to be recompiled in a derived work using Ubuntu project binary KDE packages?
-jef
Posted Jul 16, 2015 22:56 UTC (Thu)
by rahvin (guest, #16953)
[Link] (25 responses)
So even if Canonical puts terms in that violate the GPL if they enforce them, but then don't enforce them they aren't violating the GPL IMO (others probably disagree). But the second that company that purchases them tries to enforce them they have 100% violated the GPL and lost all rights for the software they violated it on.
IMO there is every argument to be made that because Canonical doesn't control access to binaries and allows free redistribution that they've forgone the very control they claim to keep. As others have noted Redhat makes similar claims and does limit download of the binaries to those with an actual formal agreement. Personally I'm not afraid of these Canonical terms, there is nothing in them that could give Canonical or some future owner the right to come after me. They could try to sue me, and it might cost me a lot of money in legal fees but they would lose in the end. And situations like that often end up with the loser paying the legal fees because Canonical didn't have a case and should have known it. The new FSF negotiated catch all term just gives you an easy summary judgement motion to end such a lawsuit early, but even without it you'd probably win either way.
This is no way should be taken as me saying what I think they are doing is right. I think it's stupid stupid policy and it's only going to hurt Canonical. I can see others being worried about being sued and the financial burden of legal protection being too great and deciding to rebase off a distribution without such language.
Posted Jul 17, 2015 3:08 UTC (Fri)
by jspaleta (subscriber, #50639)
[Link] (24 responses)
The reality is serious potential customers are going to shy away from relying on Ubuntu for derivative work...if they IP terms and the fees for use of the binaries are not crystal clear. You might not be scared of a legal fight, but the reality is serious startups are going to go look at that IP policy and back away from Ubuntu and Canonical will lose business. Unsubstantiated rumor is this has already happened with Valve.
I'm actually trying to help them get their crap together. The ambiguity of the IP policy is not in their best interest. Regardless of legal validity..its the ambiguity of the exactly what the licensing terms are which is going to kill the business model..wahtever the business model actual is here.
-jef
Posted Jul 17, 2015 3:23 UTC (Fri)
by dlang (guest, #313)
[Link] (23 responses)
please stop spreading FUD
Posted Jul 17, 2015 3:57 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link] (22 responses)
Posted Jul 17, 2015 4:13 UTC (Fri)
by jspaleta (subscriber, #50639)
[Link] (21 responses)
None of the RHEL derivatives reuse RHEL binaries built by RH.. they all rebuild from source.. as far as I am aware. I'm not even aware of a CentOS derivative that reuses CentOS built binaries (now built by RH as well technically).
The Canonical situation is different in that they are claiming that you cannot just take things like X.org binaries provided by Ubuntu and use those binaries in a derivative without needing some sort of license form Canonical. A mixture of MIT licensed Xorg binaries from Ubuntu repositories and binaries from elsewhere can't exist without canonical's assent as they claim to own the copyright to the binaries for Xorg packages. Xorg is just an example, any BSD or MIT licensed binary Canonical builds and distributes is subject to these copyright restrictions. (L)GPL'd packages are an entirely different matter, now corrected by the new IP policy clause. Details details details.
The RHEL ecoysystem doesn't have this particular issue because RHEL binaries are basically not publicly available and the terms of the subscriber agreement for RHEL make it very unlikely that any subscriber would do this sort of thing..or else lose access to future updates. I'm not aware of RH claiming its not allowed however, you'd just have your subscription turned off and you'd lose access to further binaries. This definitely is not something I've ever seen claimed by Fedora and there were derived things out there that mixed binaries like this in the Fedorascape at some point.
And all of this is separate from any trademark policy, which are not currently in dispute as far as I am aware.
Posted Jul 17, 2015 4:48 UTC (Fri)
by dlang (guest, #313)
[Link] (20 responses)
and why are people not screaming that this is "adding additional restrictions" to the GPL?
Posted Jul 17, 2015 4:59 UTC (Fri)
by jspaleta (subscriber, #50639)
[Link] (3 responses)
And to be clear Canonical's policy doesn't violate the GPL any more either. It did before the FSF and SFC got involved.
-jef
Posted Jul 17, 2015 5:24 UTC (Fri)
by mjblenner (subscriber, #53463)
[Link] (2 responses)
Citation needed. The old policy had a trump clause too, just not as prominent.
From: http://www.ubuntu.com/legal/terms-and-policies/intellectu...
"This does not affect your rights under any open source licence applicable to any of the components of Ubuntu."
Posted Jul 17, 2015 5:31 UTC (Fri)
by jspaleta (subscriber, #50639)
[Link] (1 responses)
Please read:
In particular the section titled "Why The Original Policy Violated"
Posted Jul 17, 2015 5:45 UTC (Fri)
by mjblenner (subscriber, #53463)
[Link]
Am I? The bit I quoted wasn't in the trademark section.
The SFC talked about recompiling binaries as being one example of GPL violation.
Here's the old license with a bit more context:
"Otherwise you must remove and replace the Trademarks and will need to recompile the source code to create your own binaries. This does not affect your rights under any open source licence applicable to any of the components of Ubuntu"
Doesn't the second sentence trump the "recompile" when the open source licence is GPL? (I'll agree that it's badly worded and has copyright and trademarks both in there)
Posted Jul 17, 2015 5:45 UTC (Fri)
by mjblenner (subscriber, #53463)
[Link] (15 responses)
From the RHEL license:
"At the same time, the combined body of work that constitutes Red Hat Enterprise Linux is a collective work which has been organized by Red Hat, and Red Hat holds the copyright in that collective work. Red Hat then permits others to copy, modify and redistribute the collective work. To grant this permission Red Hat usually uses the GNU General Public License (“GPL”) version 2 and Red Hat’s own End User License Agreement."
The end user license agreement looks a lot like Canonical's IP license (trademarks and such, strip all branding). So is that "additional restrictions on the GPL"?
Also, does that include the source of RHEL?
Posted Jul 17, 2015 16:34 UTC (Fri)
by mjg59 (subscriber, #23239)
[Link] (14 responses)
The net effect of Red Hat's license certainly has some similarities to Canonical's policy, but the details are significantly different.
Posted Jul 17, 2015 17:33 UTC (Fri)
by nybble41 (subscriber, #55106)
[Link] (13 responses)
Trademark law isn't restricting you; Red Hat is restricting you from using "their" trademark, as permitted by trademark law. That should count as an additional restriction imposed by Red Hat, no different than if they tried to restrict redistribution on the basis that it would infringe on their copyrights or patents.
Posted Jul 17, 2015 17:43 UTC (Fri)
by mjg59 (subscriber, #23239)
[Link] (12 responses)
"For example, some licenses say that they don't give you permission to use certain trademarks. That's not really an additional restriction: if that clause wasn't there, you still wouldn't have permission to use the trademark. We always said those licenses were compatible with GPLv2, too."
(from http://www.gnu.org/licenses/quick-guide-gplv3.en.html)
Posted Jul 17, 2015 18:35 UTC (Fri)
by dlang (guest, #313)
[Link] (9 responses)
But "don't you dare distribute the binaries or we'll cut off the support contract you paid for" is not "don't mislead people into thinking that you are us" which is what trademark is all about.
Posted Jul 17, 2015 18:44 UTC (Fri)
by mjg59 (subscriber, #23239)
[Link] (8 responses)
Right. The question is whether Red Hat are imposing an additional restriction on the distribution of GPLed material, and the answer is that they aren't.
Posted Jul 17, 2015 20:00 UTC (Fri)
by dlang (guest, #313)
[Link] (7 responses)
they are both saying "you can't distribute our binaries to anyone unless <non-GPL terms>"
but Redhat is getting a pass while people are dragging out all sorts of things that Canonical could theoretically do, but hasn't done, and pointing out how evil it is that they could do these things.
Why is RedHat putting things in it's contracts that prevent people redistributing what they get (as long as what they are doing does not cause consumer confusion which is what Trademark law addresses) acceptable, but other distros doing what looks like the same thing 'utter evil'
Posted Jul 17, 2015 20:07 UTC (Fri)
by mjg59 (subscriber, #23239)
[Link] (6 responses)
They're being treated differently because they're doing different things.
> they are both saying "you can't distribute our binaries to anyone unless <non-GPL terms>"
No. Red Hat does not impose any additional restrictions on your ability to distribute binaries. If you have the binaries and if distributing the binaries would not infringe upon Red Hat's trademarks, you can give them to anybody else. Canonical's policy explicitly prevented you from distributing those binaries.
> people are dragging out all sorts of things that Canonical could theoretically do, but hasn't done
They wrote a policy that states that you're not permitted to redistribute binaries. There's at least one case of them using this policy to force an Ubuntu derivative to pay for a license from them. What's theoretical about this situation?
> Why is RedHat putting things in it's contracts that prevent people redistributing what they get
They're not?
Posted Jul 17, 2015 20:39 UTC (Fri)
by dlang (guest, #313)
[Link] (5 responses)
"if you distribute binaries or patches you loose access to updates that you have paid a support contract for" isn't a restriction on your ability to distribute binaries???
Posted Jul 17, 2015 20:56 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Jul 17, 2015 20:56 UTC (Fri)
by mjg59 (subscriber, #23239)
[Link] (2 responses)
Correct. It's a repugnant part of Red Hat's strategy, but it does nothing to stop you from distributing the binaries. The GPL can't compel a company to continue doing business with you if they choose not to.
Posted Jul 18, 2015 0:33 UTC (Sat)
by drag (guest, #31333)
[Link] (1 responses)
Another possible way to look at this is that the GPL is a copyright license and as such it's limited in scope by copyright law itself.
It doesn't deal with patents or trademarks. Also it is not a contract establishing indentured servitude between you and the person that handed you the software.
Also another thing to keep in mind that is that Canonical is not a USA corporation. Typically when people talk about GPL it's in the context of USA copyright law, because that is still the biggest market for this stuff. The ability to license distribution of binaries may be significantly different in a UK or South African's lawyer's eyes then a American. This copyright stuff is completely arbitrary and doesn't really make a whole lot of sense, fundamentally. I find it dismaying that people are so ready to condemn companies like Canonical and act like they are the evil guys here.
Running into conflicts with subtle interpretations of a country's laws doesn't make a business illegal or immoral or turn the violators into assholes that need to be publicly humiliated and condemned. It seems that most people really involved in trying to resolve these issues and elucidate the public seem to be trying to be respectful for the most part, which is excellent. It's the peanut gallery that, I feel, needs to step back and take a breather. Canonical has problems, but so does everybody else on the planet.
I say the best thing to do is just sit back and let the copyright holders themselves deal with things in a constructive manner. Trying to 'put pressure' on people and criticism almost never works and just makes people go on the defensive and only consider the justifications for their actions rather then engage in improvements or try to deal constructively with the 'community'.
Also I am going to try to remember this stuff when the BSD folks criticize the GPL and point out how it can create a legal morass for the people that try to use it in their products. It's not a easy thing to deal with, even though the view from a thousand feet above makes everything seems so obvious.
Posted Jul 18, 2015 1:20 UTC (Sat)
by mjg59 (subscriber, #23239)
[Link]
In this case the attempt to deal with it in a constructive manner has taken years and resulted in the bare minimum fix required to ensure that Canonical aren't breaching copyright law. The policy overall is still a hostile act on their part, and so I think it's reasonable for the wider community to point out the ways that it makes their lives difficult.
Posted Jul 17, 2015 20:57 UTC (Fri)
by jspaleta (subscriber, #50639)
[Link]
It really doesn't matter which entity turns off the subscription.. red hat or the customer.. nor does it matter for what reason. At the end of the day, the customer can do whatever they want with the binaries they have in hand. They just won't be Red Hat customers any longer and will not be getting updates. If a customer chooses to stop paying Red Hat, they can redistribute the binaries they have. Red Hat cannot compelling them to become paying customers again. Nor can Red Hat compel them via legal means to stop distributing the binaries.
Posted Jul 18, 2015 3:11 UTC (Sat)
by nybble41 (subscriber, #55106)
[Link] (1 responses)
I agree, their position is clear. I also think it's contrary to the plain meaning of the text of the GPLv2:
> 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.
I fail to see any way in which a restriction on redistribution (with or without modification) on the basis of a trademark claim could avoid constituting the imposition of a further restriction "on the recipients' exercise of the rights granted herein."
Section 7 says that you can't distribute a GPLv2 program if a third-party patent license would be required for downstream recipients to exercise their rights (such as the creation and distribution of derivative works) under the GPL. It doesn't say that it's acceptable to require recipients to remove or replace portions of the code covered by the patent. The only reason the contributor's own patents are not mentioned is that permission to use them in connection with the program is implied by the existing terms. Why would the same logic not apply in the case of trademarks? A requirement that recipients strip out or trademarks already in the codebase prior to distributing modifications is not substantially different from a requirement to strip out a patented algorithm.
Posted Jul 19, 2015 9:55 UTC (Sun)
by dlang (guest, #313)
[Link]
But removing trademarks is also only a requirement if not doing so could create confusion in the recipient as to who is backing the software or who they got it from. If there's no chance of such confusion, then there's no trademark violation (and therefor no license for the trademark needed)
Posted Jul 15, 2015 17:10 UTC (Wed)
by coriordan (guest, #7544)
[Link]
For example, if they intend their GPL'd software to be included in their definition of "Canonical IP" then this part from the start of the policy is incorrect:
Your use of Canonical IP is subject to:
If they publish something under the GPL then you have the right to use it for any purpose and your rights are not subject to accepting an "IPRights Policy" from Canonical or from anyone else. That's what's great about the GPL. So I don't know what to make of this part: "Your continued use of Canonical IP implies your acceptance and acknowledgement of this IPRights Policy."
One way a judge could resolve this contradiction would be to suppose that Canonical doesn't intend GPL and other copyleft software to be included in their definition of "Canonical IP", which means their attempt to claim rights they don't have would actually backfire.
Anyone else got different readings of it?
FSF and SFC work with Canonical on an "intellectual property" policy update
FSF and SFC work with Canonical on an "intellectual property" policy update
Seems like it but it's just my opinion so waddoeyeknow.
FSF and SFC work with Canonical on an "intellectual property" policy update
FSF and SFC work with Canonical on an "intellectual property" policy update
FSF and SFC work with Canonical on an "intellectual property" policy update
FSF and SFC work with Canonical on an "intellectual property" policy update
FSF and SFC work with Canonical on an "intellectual property" policy update
FSF and SFC work with Canonical on an "intellectual property" policy update
FSF and SFC work with Canonical on an "intellectual property" policy update
FSF and SFC work with Canonical on an "intellectual property" policy update
FSF and SFC work with Canonical on an "intellectual property" policy update
FSF and SFC work with Canonical on an "intellectual property" policy update
FSF and SFC work with Canonical on an "intellectual property" policy update
http://lwn.net/Articles/431854/
http://ebb.org/bkuhn/blog/2011/03/11/linux-red-hat-gpl.html
http://ebb.org/bkuhn/blog/2011/03/05/open-core-slur.html
Now the problems with Canonical's IP policy are about everything else but the GPL code. It's still a lot of code. I can't wait to see what Canonical legal says about the perhaps tens of Ubuntu remixed docker images sort of floating around out there that might be out of compliance.
FSF and SFC work with Canonical on an "intellectual property" policy update
FSF and SFC work with Canonical on an "intellectual property" policy update
You just quoted a section of their IP policy specific to their trademarks. The trademarks are not in dispute.
If you can't wrap your head around the different between the copyright claims and the trademark claims, I'm not sure how to help you.
https://sfconservancy.org/news/2015/jul/15/ubuntu-ip-policy/
FSF and SFC work with Canonical on an "intellectual property" policy update
FSF and SFC work with Canonical on an "intellectual property" policy update
FSF and SFC work with Canonical on an "intellectual property" policy update
FSF and SFC work with Canonical on an "intellectual property" policy update
FSF and SFC work with Canonical on an "intellectual property" policy update
FSF and SFC work with Canonical on an "intellectual property" policy update
FSF and SFC work with Canonical on an "intellectual property" policy update
FSF and SFC work with Canonical on an "intellectual property" policy update
FSF and SFC work with Canonical on an "intellectual property" policy update
FSF and SFC work with Canonical on an "intellectual property" policy update
FSF and SFC work with Canonical on an "intellectual property" policy update
FSF and SFC work with Canonical on an "intellectual property" policy update
FSF and SFC work with Canonical on an "intellectual property" policy update
FSF and SFC work with Canonical on an "intellectual property" policy update
FSF and SFC work with Canonical on an "intellectual property" policy update
FSF and SFC work with Canonical on an "intellectual property" policy update
FSF and SFC work with Canonical on an "intellectual property" policy update
FSF and SFC work with Canonical on an "intellectual property" policy update