I find it ironic that you bring up proprietary installers.. considering how fast Canonical is moving towards a business model for proprietary oem device images in their build out of snappy. Everything old is new again.
But back in 1999 when the RHL installer was proprietary was Red Hat making any claims similar to "X is made for sharing. Use it, modify it, improve it, share it. Anywhere, any time and with any number of people all over the world. No licence required."
If Canonical was self-consistent and was marketing and socializing Ubuntu the product as a proprietary product.. then this wouldn't really be as big of an issue now. There would be no confusion. But Canonical has and continues to market and socialize Ubuntu the product, as being something okay to modify and redistribute..without seeking a license to do so. The text on http://www.ubuntu.com/about/ is in direct conflict to the IP policy. And that is a huge problem. It's the lack of clarity that is the problem, not the proprietary nature of the IP policy. It's the gap between the promise and the reality that needs to be closed. The Ubunut Promise makes a big deal about the ability to modify and share...without asking for permission to do so. And yet.. the IP policy seems to say its just way easier if you get special permision to do so.
Either "the Ubuntu Promise" text needs to be updated to come into line with the reality of the newer IP policy or the IP policy needs to be redrafted to clarify.
I think most everyone outside the Canonical fenceline would prefer that the IP policy be clarified instead of the Ubuntu promise updated. But for me, I think it would be much more honest for Canonical moving forward if they just stopped trying to upsell the idea that Ubuntu is modifiable and sharable as a valueadd and marketplace differentiation. It's not as true as it use to be considering the intent of the IP policy, and it will be even less true moving forward with snappy oem images using special oem snap packages at image provisioning.
Power management, mobile and firmware developer on Linux. Security developer at nvidia. Ex-biologist. Content here should not be interpreted as the opinion of my employer. Also on Mastodon and Bluesky.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Re: Comparing to Fedora / Comparing to Red Hat
Date: 2015-11-23 06:44 pm (UTC)But back in 1999 when the RHL installer was proprietary was Red Hat making any claims similar to "X is made for sharing. Use it, modify it, improve it, share it. Anywhere, any time and with any number of people all over the world. No licence required."
If Canonical was self-consistent and was marketing and socializing Ubuntu the product as a proprietary product.. then this wouldn't really be as big of an issue now. There would be no confusion. But Canonical has and continues to market and socialize Ubuntu the product, as being something okay to modify and redistribute..without seeking a license to do so. The text on http://www.ubuntu.com/about/ is in direct conflict to the IP policy. And that is a huge problem. It's the lack of clarity that is the problem, not the proprietary nature of the IP policy. It's the gap between the promise and the reality that needs to be closed. The Ubunut Promise makes a big deal about the ability to modify and share...without asking for permission to do so. And yet.. the IP policy seems to say its just way easier if you get special permision to do so.
Either "the Ubuntu Promise" text needs to be updated to come into line with the reality of the newer IP policy or the IP policy needs to be redrafted to clarify.
I think most everyone outside the Canonical fenceline would prefer that the IP policy be clarified instead of the Ubuntu promise updated. But for me, I think it would be much more honest for Canonical moving forward if they just stopped trying to upsell the idea that Ubuntu is modifiable and sharable as a valueadd and marketplace differentiation. It's not as true as it use to be considering the intent of the IP policy, and it will be even less true moving forward with snappy oem images using special oem snap packages at image provisioning.