systemd.conf 2015 CfP REMINDER

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/systemdconf-2015-cfp-reminder.html

LAST REMINDER! systemd.conf 2015 Call for Presentations ends August 31st!

Here’s the last reminder that the systemd.conf 2015 CfP ends on August
31st 11:59:59pm Central European Time (that’s monday next week)! Make
sure to submit your proposals until then!

Please submit your proposals on our
website!

And don’t forget to register for the conference! Only a limited number of
registrations are available due to space constraints!
Register here!.

For further details about systemd.conf consult the conference website.

First Round of systemd.conf 2015 Sponsors

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/first-round-of-systemdconf-2015-sponsors.html

First Round of systemd.conf 2015 Sponsors

We are happy to announce the first round of systemd.conf
2015 sponsors!

Our first Gold sponsor is CoreOS!

CoreOS develops software for modern infrastructure that delivers a consistent operating environment for distributed applications. CoreOS’s commercial offering, Tectonic, is an enterprise-ready platform that combines Kubernetes and the CoreOS stack to run Linux containers. In addition CoreOS is the creator and maintainer of open source projects such as CoreOS Linux, etcd, fleet, flannel and rkt. The strategies and architectures that influence CoreOS allow companies like Google, Facebook and Twitter to run their services at scale with high resilience. Learn more about CoreOS here https://coreos.com/, Tectonic here, https://tectonic.com/ or follow CoreOS on Twitter @coreoslinux.

A Silver sponsor is Codethink:

Codethink is a software services consultancy, focusing on engineering reliable systems for long-term deployment with open source technologies.

A Bronze sponsor is Pantheon:

Pantheon is a platform for professional website development, testing, and deployment. Supporting Drupal and WordPress, Pantheon runs over 100,000 websites for the world’s top brands, universities, and media organizations on top of over a million containers.

A Bronze sponsor is Pengutronix:

Pengutronix provides consulting, training and development services for Embedded Linux to customers from the industry. The Kernel Team ports Linux to customer hardware and has more than 3100 patches in the official mainline kernel. In addition to lowlevel ports, the Pengutronix Application Team is responsible for board support packages based on PTXdist or Yocto and deals with system integration (this is where systemd plays an important role). The Graphics Team works on accelerated multimedia tasks, based on the Linux kernel, GStreamer, Qt and web technologies.

We’d like to thank our sponsors for their support! Without sponsors our conference would not be possible!

We’ll shortly announce our second round of sponsors, please stay tuned!

If you’d like to join the ranks of systemd.conf 2015 sponsors, please have a look at our Becoming a Sponsor page!

Reminder! The systemd.conf 2015 Call for Presentations ends on monday, August 31st! Please make sure to submit your proposals on the CfP page until then!

Also, don’t forget to register for the conference! Only a limited number of
registrations are available due to space constraints!
Register here!.

For further details about systemd.conf consult the conference website.

JavaScript private methods and variables

Post Syndicated from Anonymous original http://deliantech.blogspot.com/2015/08/javascript-private-methods-and-variables.html

Often I am told that JavaScript has no real private methods and variables the same way as this is for Python or Perl.
Although, that is true for Python and Perl (all scopes and their content are publicly accessible and there is always a way to list and access the content) it is not true for JavaScript.
JavaScript have one of the most powerful scoping technique available for a main-stream programing language and provides you with the ability to hide and make private some content if needed.
Let me show you an example:
function MyClass() {
    var fullyPrivateVar = ‘xxxx’;
    this.notFullyPrivateVar = ‘yyyy’;

    function privateMethod() {
        return fullyPrivateVar;
    }

    this.publicMethodWithPrivateAccess = function() { return privateMethod() }
}

MyClass.prototype.publicMethodWithNoPrivateAccess = function() {
    return this.notFullyPrivateVar;
}

x = new MyClass();
console.log(x.publicMethodWithNoPrivateAccess());
yyyy
console.log(x.publicMethodWithPrivateAccess());
xxxx

I think the example is self explanatory, but let me say few words on it:
In JavaScript you can have hierarchy of scopes and you can define unlimited amount function in functions levels (and scope levels) in difference to other programming languages where you have limited / fixed scope levels.
So I have a privateMethod and fullyPrivateVar defined within MyClass. Because of it, only things defined in this scope will have access to them. Like publicMethodWithPrivateAccess that I assign with the constructor to the newly constructed object. However,  publicMethodWithNoPrivateAccess is defined outside of the scope and has no access to those values. But it has access to everything in the this scope. One could argue, that this approach takes more memory for the methods because I define a new method with every initialization of the class (the function assignment). But that is not true. The function in the function is having a static code (it is not part of eval+variable) and is compiled during the initial javascript processing of the JS virtual machine. So it will not take extra memory. Only during execution the function will be dynamically assigned with the private scope of the constructor, something you want anyway.

systemd.conf 2015 Call for Presentations

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/systemdconf-2015-call-for-presentations.html

REMINDER! systemd.conf 2015 Call for Presentations ends August 31st!

We’d like to remind you that the systemd.conf 2015 Call for Presentations ends
on August 31st! Please submit your presentation proposals before that data
on our website.

We are specifically interested in submissions from projects and vendors building
today’s and tomorrow’s products, services and devices with systemd. We’d like to
learn about the problems you encounter and the benefits you see! Hence, if
you work for a company using systemd, please submit a presentation!

We are also specifically interested in submissions from downstream distribution
maintainers of systemd! If you develop or maintain systemd packages in a
distribution, please submit a presentation reporting about the state, future
and the problems of systemd packaging so that we can improve downstream
collaboration!

And of course, all talks regarding systemd usage in containers, in the cloud,
on servers, on the desktop, in mobile and in embedded are highly welcome! Talks
about systemd networking and kdbus IPC are very welcome too!

Please submit your presentations until August 31st!

And don’t forget to register for the conference! Only a limited number of
registrations are available due to space constraints!
Register here!.

Also, limited travel and entry fee sponsorship is available for community contributors. Please contact us for details!

For further details about the CfP consult the CfP page.

For further details about systemd.conf consult the conference website.

Announcing systemd.conf 2015

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/announcing-systemdconf-2015.html

Announcing systemd.conf 2015

We are happy to announce the inaugural systemd.conf 2015 conference of the systemd project.

The conference takes place November 5th-7th, 2015 in Berlin, Germany.

Only a limited number of tickets are available, hence make sure to sign up quickly.

For further details consult the conference website.

Thoughts on Canonical, Ltd.’s Updated Ubuntu IP Policy

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2015/07/15/ubuntu-ip-policy.html

Most of you by now have probably
seen Conservancy’s
and FSF’s
statements regarding
the today’s
update to Canonical, Ltd.’s Ubuntu IP Policy. I have a few personal
comments, speaking only for myself, that I want to add that don’t appear
in the FSF’s nor Conservancy’s analysis. (I wrote nearly all of
Conservancy’s analysis and did some editing on FSF’s analysis, but the
statements here I add are my personal opinions and don’t necessarily
reflect the views of the FSF nor Conservancy, notwithstanding that I have
affiliations with both orgs.)

First of all, I think it’s important to note the timeline: it took two
years of work by two charities to get this change done. The scary thing is
that compared to their peers who have also violated the GPL, Canonical,
Ltd. acted rather quickly.
As Conservancy
pointed out regarding the VMware lawsuit, it’s not uncommon for these
negotiations to take even four years before we all give up and have to file
a lawsuit. So, Canonical, Ltd. resolved the matter at least twice
as fast as VMware, and they deserve some credit for that — even if
other GPL violators have set the bar quite low.

Second, I have to express my sympathy for the positions on this matter
taken by Matthew
Garrett and Jonathan
Riddell. Their positions show clearly that, while the GPL violation is
now fully resolved, the community is very concerned about what the happens
regarding non-copylefted software in Ubuntu, and thus Ubuntu as a
whole.

Realize, though, that these trump clauses are widely used throughout the
software industry. For example, electronics manufacturers who ship an
Android/Linux system with standard, disgustingly worded, forbid-everything
EULA usually include a trump clause not unlike Ubuntu’s. In such systems,
usually, the only copylefted program is the kernel named Linux. The rest
of the distribution includes tons of (now proprietarized) non-copylefted
code from Android (as well as a bunch of born-proprietary applications
too). The trump clause assures the software freedom rights for that one
copylefted work present, but all the non-copylefted ones are subject to the
strict EULA (which often includes “no reverse engineer
clauses”, etc.). That means if the electronics company did change
the Android Java code in some way, you can’t even legally reverse engineer
it — even though it was Apache-licensed by upstream.

Trump clauses are thus less than ideal because they achieve compliance
only by allowing a copyleft to prevail when the overarching license
contradicts specific requirements, permissions, or rights under copyleft.
That’s acceptable because copyleft licenses have many important clauses
that assure and uphold software freedom. By contrast, most non-copyleft
licenses have very few requirements, and thus they lack adequate terms to
triumph over any anti-software-freedom terms of the overarching license.
For example, if I take a 100% ISC-licensed program and build a
binary from it, nothing in the ISC license prohibits me from imposing this
license on you: “you may not redistribute this binary
commercially”. Thus, even if I also say to you: “but also, if
the ISC license grants rights, my aforementioned license does not modify or
reduce those rights”, nothing has changed for you. You still have a
binary that you can’t distribute commercially, and there was no text in the
ISC license to force the trump clause to save you.

Therefore, this whole situation is a simple and clear argument for why
copyleft matters. Copyleft can and does (when someone like me actually
enforces it) prevent such situations. But copyleft is not infinitely
expansive. Nearly every full operating system distribution available
includes an aggregated mix of copylefted, non-copyleft, and often
fully-proprietary userspace applications. Nearly every company that
distributes them wraps the whole thing with some agreement that restricts
some rights that copyleft defends, and then adds a trump clause that gives
an exception just for FLOSS license compliance. Sadly, I have yet to see a
company trailblaze adoption of a “software freedom
preservation” clause that guarantees copyleft-like compliance for
non-copylefted programs and packages. Thus, the problem with Ubuntu is
just a particularly bad example of what has become a standard industry
practice by nearly every “open source” company.

How badly these practices impact software freedom depends on the
strictness and detailed terms of the overarching license
(and not the contents of the trump clause itself; they are
generally isomorphic0). The task of analyzing and
rating “relative badness” of each overarching licensing
document is monumental; there are probably thousands of different ones in
use today. Matthew Garrett points out why Canonical, Ltd.’s is
particularly bad, but that doesn’t mean there aren’t worse (and better)
situations of a similar ilk. Perhaps our next best move is to use copyleft
licenses more often, so that the trump clauses actually do more.

In other words, as long as there is non-copylefted software aggregated in a
given distribution of an otherwise Free Software system, companies will
seek to put non-Free terms on top of the non-copylefted parts, To my
knowledge, every distribution-shipping company (except for
extremely rare, Free-Software-focused companies like ThinkPenguin) place
some kind of restrictions in their business terms for their enterprise
distribution products. Everyone seems to be asking me today to build the
“worst to almost-benign” ranking of these terms, but I’ve
resisted the urge to try. I think the safe bet is to assume that if you’re
looking at one of these trump clauses, there is some sort of
software-freedom-unfriendly restriction floating around in the broader
agreement, and you should thus just avoid that product entirely. Or, if
you really want to use it, fork it from source and relicense the
non-copylefted stuff under copyleft licenses (which is permitted by nearly
all non-copyleft licenses), to prevent future downstream actors from adding
more restrictive terms. I’d even suggest this as a potential solution to
the current Ubuntu problem (or, better yet, just go back upstream to Debian
and do the same :).

Finally, IMO the biggest problem with these “overarching licenses
with a trump clause” is their use by companies who herald “open
source” friendliness. I suspect the community ire comes from a sense
of betrayal. Yet, I feel only my usual anger at proprietary software here;
I don’t feel betrayed. Rather, this is just another situation that proves
that
saying you are an “open source company” isn’t enough;
only the company’s actions and “fine print” terms matter. Now
that open source has really succeeded at coopting software freedom,
enormous effort is now required to ascertain if any company respects your
software freedom. We must ignore the ballyhoo of “community
managers” and look closely at the real story.

0Despite Canonical,
Ltd.’s use of a trump clause, I don’t think these various trump
clauses are canonically isomorphic. There is no natural mapping
between these various trump clauses, but they all do have the same
effect: they assure that when the overarching terms conflict with
the a FLOSS license, the FLOSS license triumphs over the
overarching terms, no matter what they are. However, the
potential relevance of the phrase “canonical
isomorphism” here is yet another example why it’s confusing
and insidious that Canonical, Ltd. insisted so strongly
on using
canonical in a non-canonical way.

Thoughts on Canonical, Ltd.’s Updated Ubuntu IP Policy

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2015/07/15/ubuntu-ip-policy.html

Most of you by now have probably
seen Conservancy’s
and FSF’s
statements regarding
the today’s
update to Canonical, Ltd.’s Ubuntu IP Policy. I have a few personal
comments, speaking only for myself, that I want to add that don’t appear
in the FSF’s nor Conservancy’s analysis. (I wrote nearly all of
Conservancy’s analysis and did some editing on FSF’s analysis, but the
statements here I add are my personal opinions and don’t necessarily
reflect the views of the FSF nor Conservancy, notwithstanding that I have
affiliations with both orgs.)

First of all, I think it’s important to note the timeline: it took two
years of work by two charities to get this change done. The scary thing is
that compared to their peers who have also violated the GPL, Canonical,
Ltd. acted rather quickly.
As Conservancy
pointed out regarding the VMware lawsuit, it’s not uncommon for these
negotiations to take even four years before we all give up and have to file
a lawsuit. So, Canonical, Ltd. resolved the matter at least twice
as fast as VMware, and they deserve some credit for that — even if
other GPL violators have set the bar quite low.

Second, I have to express my sympathy for the positions on this matter
taken by Matthew
Garrett and Jonathan
Riddell. Their positions show clearly that, while the GPL violation is
now fully resolved, the community is very concerned about what the happens
regarding non-copylefted software in Ubuntu, and thus Ubuntu as a
whole.

Realize, though, that these trump clauses are widely used throughout the
software industry. For example, electronics manufacturers who ship an
Android/Linux system with standard, disgustingly worded, forbid-everything
EULA usually include a trump clause not unlike Ubuntu’s. In such systems,
usually, the only copylefted program is the kernel named Linux. The rest
of the distribution includes tons of (now proprietarized) non-copylefted
code from Android (as well as a bunch of born-proprietary applications
too). The trump clause assures the software freedom rights for that one
copylefted work present, but all the non-copylefted ones are subject to the
strict EULA (which often includes “no reverse engineer
clauses”, etc.). That means if the electronics company did change
the Android Java code in some way, you can’t even legally reverse engineer
it — even though it was Apache-licensed by upstream.

Trump clauses are thus less than ideal because they achieve compliance
only by allowing a copyleft to prevail when the overarching license
contradicts specific requirements, permissions, or rights under copyleft.
That’s acceptable because copyleft licenses have many important clauses
that assure and uphold software freedom. By contrast, most non-copyleft
licenses have very few requirements, and thus they lack adequate terms to
triumph over any anti-software-freedom terms of the overarching license.
For example, if I take a 100% ISC-licensed program and build a
binary from it, nothing in the ISC license prohibits me from imposing this
license on you: “you may not redistribute this binary
commercially”. Thus, even if I also say to you: “but also, if
the ISC license grants rights, my aforementioned license does not modify or
reduce those rights”, nothing has changed for you. You still have a
binary that you can’t distribute commercially, and there was no text in the
ISC license to force the trump clause to save you.

Therefore, this whole situation is a simple and clear argument for why
copyleft matters. Copyleft can and does (when someone like me actually
enforces it) prevent such situations. But copyleft is not infinitely
expansive. Nearly every full operating system distribution available
includes an aggregated mix of copylefted, non-copyleft, and often
fully-proprietary userspace applications. Nearly every company that
distributes them wraps the whole thing with some agreement that restricts
some rights that copyleft defends, and then adds a trump clause that gives
an exception just for FLOSS license compliance. Sadly, I have yet to see a
company trailblaze adoption of a “software freedom
preservation” clause that guarantees copyleft-like compliance for
non-copylefted programs and packages. Thus, the problem with Ubuntu is
just a particularly bad example of what has become a standard industry
practice by nearly every “open source” company.

How badly these practices impact software freedom depends on the
strictness and detailed terms of the overarching license
(and not the contents of the trump clause itself; they are
generally isomorphic0). The task of analyzing and
rating “relative badness” of each overarching licensing
document is monumental; there are probably thousands of different ones in
use today. Matthew Garrett points out why Canonical, Ltd.’s is
particularly bad, but that doesn’t mean there aren’t worse (and better)
situations of a similar ilk. Perhaps our next best move is to use copyleft
licenses more often, so that the trump clauses actually do more.

In other words, as long as there is non-copylefted software aggregated in a
given distribution of an otherwise Free Software system, companies will
seek to put non-Free terms on top of the non-copylefted parts, To my
knowledge, every distribution-shipping company (except for
extremely rare, Free-Software-focused companies like ThinkPenguin) place
some kind of restrictions in their business terms for their enterprise
distribution products. Everyone seems to be asking me today to build the
“worst to almost-benign” ranking of these terms, but I’ve
resisted the urge to try. I think the safe bet is to assume that if you’re
looking at one of these trump clauses, there is some sort of
software-freedom-unfriendly restriction floating around in the broader
agreement, and you should thus just avoid that product entirely. Or, if
you really want to use it, fork it from source and relicense the
non-copylefted stuff under copyleft licenses (which is permitted by nearly
all non-copyleft licenses), to prevent future downstream actors from adding
more restrictive terms. I’d even suggest this as a potential solution to
the current Ubuntu problem (or, better yet, just go back upstream to Debian
and do the same :).

Finally, IMO the biggest problem with these “overarching licenses
with a trump clause” is their use by companies who herald “open
source” friendliness. I suspect the community ire comes from a sense
of betrayal. Yet, I feel only my usual anger at proprietary software here;
I don’t feel betrayed. Rather, this is just another situation that proves
that
saying you are an “open source company” isn’t enough;
only the company’s actions and “fine print” terms matter. Now
that open source has really succeeded at coopting software freedom,
enormous effort is now required to ascertain if any company respects your
software freedom. We must ignore the ballyhoo of “community
managers” and look closely at the real story.

0Despite Canonical,
Ltd.’s use of a trump clause, I don’t think these various trump
clauses are canonically isomorphic. There is no natural mapping
between these various trump clauses, but they all do have the same
effect: they assure that when the overarching terms conflict with
the a FLOSS license, the FLOSS license triumphs over the
overarching terms, no matter what they are. However, the
potential relevance of the phrase “canonical
isomorphism” here is yet another example why it’s confusing
and insidious that Canonical, Ltd. insisted so strongly
on using
canonical in a non-canonical way.

Thoughts on Canonical, Ltd.’s Updated Ubuntu IP Policy

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2015/07/15/ubuntu-ip-policy.html

Most of you by now have probably
seen Conservancy’s
and FSF’s
statements regarding
the today’s
update to Canonical, Ltd.’s Ubuntu IP Policy. I have a few personal
comments, speaking only for myself, that I want to add that don’t appear
in the FSF’s nor Conservancy’s analysis. (I wrote nearly all of
Conservancy’s analysis and did some editing on FSF’s analysis, but the
statements here I add are my personal opinions and don’t necessarily
reflect the views of the FSF nor Conservancy, notwithstanding that I have
affiliations with both orgs.)

First of all, I think it’s important to note the timeline: it took two
years of work by two charities to get this change done. The scary thing is
that compared to their peers who have also violated the GPL, Canonical,
Ltd. acted rather quickly.
As Conservancy
pointed out regarding the VMware lawsuit, it’s not uncommon for these
negotiations to take even four years before we all give up and have to file
a lawsuit. So, Canonical, Ltd. resolved the matter at least twice
as fast as VMware, and they deserve some credit for that — even if
other GPL violators have set the bar quite low.

Second, I have to express my sympathy for the positions on this matter
taken by Matthew
Garrett and Jonathan
Riddell. Their positions show clearly that, while the GPL violation is
now fully resolved, the community is very concerned about what the happens
regarding non-copylefted software in Ubuntu, and thus Ubuntu as a
whole.

Realize, though, that these trump clauses are widely used throughout the
software industry. For example, electronics manufacturers who ship an
Android/Linux system with standard, disgustingly worded, forbid-everything
EULA usually include a trump clause not unlike Ubuntu’s. In such systems,
usually, the only copylefted program is the kernel named Linux. The rest
of the distribution includes tons of (now proprietarized) non-copylefted
code from Android (as well as a bunch of born-proprietary applications
too). The trump clause assures the software freedom rights for that one
copylefted work present, but all the non-copylefted ones are subject to the
strict EULA (which often includes “no reverse engineer
clauses”, etc.). That means if the electronics company did change
the Android Java code in some way, you can’t even legally reverse engineer
it — even though it was Apache-licensed by upstream.

Trump clauses are thus less than ideal because they achieve compliance
only by allowing a copyleft to prevail when the overarching license
contradicts specific requirements, permissions, or rights under copyleft.
That’s acceptable because copyleft licenses have many important clauses
that assure and uphold software freedom. By contrast, most non-copyleft
licenses have very few requirements, and thus they lack adequate terms to
triumph over any anti-software-freedom terms of the overarching license.
For example, if I take a 100% ISC-licensed program and build a
binary from it, nothing in the ISC license prohibits me from imposing this
license on you: “you may not redistribute this binary
commercially”. Thus, even if I also say to you: “but also, if
the ISC license grants rights, my aforementioned license does not modify or
reduce those rights”, nothing has changed for you. You still have a
binary that you can’t distribute commercially, and there was no text in the
ISC license to force the trump clause to save you.

Therefore, this whole situation is a simple and clear argument for why
copyleft matters. Copyleft can and does (when someone like me actually
enforces it) prevent such situations. But copyleft is not infinitely
expansive. Nearly every full operating system distribution available
includes an aggregated mix of copylefted, non-copyleft, and often
fully-proprietary userspace applications. Nearly every company that
distributes them wraps the whole thing with some agreement that restricts
some rights that copyleft defends, and then adds a trump clause that gives
an exception just for FLOSS license compliance. Sadly, I have yet to see a
company trailblaze adoption of a “software freedom
preservation” clause that guarantees copyleft-like compliance for
non-copylefted programs and packages. Thus, the problem with Ubuntu is
just a particularly bad example of what has become a standard industry
practice by nearly every “open source” company.

How badly these practices impact software freedom depends on the
strictness and detailed terms of the overarching license
(and not the contents of the trump clause itself; they are
generally isomorphic0). The task of analyzing and
rating “relative badness” of each overarching licensing
document is monumental; there are probably thousands of different ones in
use today. Matthew Garrett points out why Canonical, Ltd.’s is
particularly bad, but that doesn’t mean there aren’t worse (and better)
situations of a similar ilk. Perhaps our next best move is to use copyleft
licenses more often, so that the trump clauses actually do more.

In other words, as long as there is non-copylefted software aggregated in a
given distribution of an otherwise Free Software system, companies will
seek to put non-Free terms on top of the non-copylefted parts, To my
knowledge, every distribution-shipping company (except for
extremely rare, Free-Software-focused companies like ThinkPenguin) place
some kind of restrictions in their business terms for their enterprise
distribution products. Everyone seems to be asking me today to build the
“worst to almost-benign” ranking of these terms, but I’ve
resisted the urge to try. I think the safe bet is to assume that if you’re
looking at one of these trump clauses, there is some sort of
software-freedom-unfriendly restriction floating around in the broader
agreement, and you should thus just avoid that product entirely. Or, if
you really want to use it, fork it from source and relicense the
non-copylefted stuff under copyleft licenses (which is permitted by nearly
all non-copyleft licenses), to prevent future downstream actors from adding
more restrictive terms. I’d even suggest this as a potential solution to
the current Ubuntu problem (or, better yet, just go back upstream to Debian
and do the same :).

Finally, IMO the biggest problem with these “overarching licenses
with a trump clause” is their use by companies who herald “open
source” friendliness. I suspect the community ire comes from a sense
of betrayal. Yet, I feel only my usual anger at proprietary software here;
I don’t feel betrayed. Rather, this is just another situation that proves
that
saying you are an “open source company” isn’t enough;
only the company’s actions and “fine print” terms matter. Now
that open source has really succeeded at coopting software freedom,
enormous effort is now required to ascertain if any company respects your
software freedom. We must ignore the ballyhoo of “community
managers” and look closely at the real story.

0Despite Canonical,
Ltd.’s use of a trump clause, I don’t think these various trump
clauses are canonically isomorphic. There is no natural mapping
between these various trump clauses, but they all do have the same
effect: they assure that when the overarching terms conflict with
the a FLOSS license, the FLOSS license triumphs over the
overarching terms, no matter what they are. However, the
potential relevance of the phrase “canonical
isomorphism” here is yet another example why it’s confusing
and insidious that Canonical, Ltd. insisted so strongly
on using
canonical in a non-canonical way.

Thoughts on Canonical, Ltd.’s Updated Ubuntu IP Policy

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2015/07/15/ubuntu-ip-policy.html

Most of you by now have probably
seen Conservancy’s
and FSF’s
statements regarding
the today’s
update to Canonical, Ltd.’s Ubuntu IP Policy. I have a few personal
comments, speaking only for myself, that I want to add that don’t appear
in the FSF’s nor Conservancy’s analysis. (I wrote nearly all of
Conservancy’s analysis and did some editing on FSF’s analysis, but the
statements here I add are my personal opinions and don’t necessarily
reflect the views of the FSF nor Conservancy, notwithstanding that I have
affiliations with both orgs.)

First of all, I think it’s important to note the timeline: it took two
years of work by two charities to get this change done. The scary thing is
that compared to their peers who have also violated the GPL, Canonical,
Ltd. acted rather quickly.
As Conservancy
pointed out regarding the VMware lawsuit, it’s not uncommon for these
negotiations to take even four years before we all give up and have to file
a lawsuit. So, Canonical, Ltd. resolved the matter at least twice
as fast as VMware, and they deserve some credit for that — even if
other GPL violators have set the bar quite low.

Second, I have to express my sympathy for the positions on this matter
taken by Matthew
Garrett and Jonathan
Riddell. Their positions show clearly that, while the GPL violation is
now fully resolved, the community is very concerned about what the happens
regarding non-copylefted software in Ubuntu, and thus Ubuntu as a
whole.

Realize, though, that these trump clauses are widely used throughout the
software industry. For example, electronics manufacturers who ship an
Android/Linux system with standard, disgustingly worded, forbid-everything
EULA usually include a trump clause not unlike Ubuntu’s. In such systems,
usually, the only copylefted program is the kernel named Linux. The rest
of the distribution includes tons of (now proprietarized) non-copylefted
code from Android (as well as a bunch of born-proprietary applications
too). The trump clause assures the software freedom rights for that one
copylefted work present, but all the non-copylefted ones are subject to the
strict EULA (which often includes “no reverse engineer
clauses”, etc.). That means if the electronics company did change
the Android Java code in some way, you can’t even legally reverse engineer
it — even though it was Apache-licensed by upstream.

Trump clauses are thus less than ideal because they achieve compliance
only by allowing a copyleft to prevail when the overarching license
contradicts specific requirements, permissions, or rights under copyleft.
That’s acceptable because copyleft licenses have many important clauses
that assure and uphold software freedom. By contrast, most non-copyleft
licenses have very few requirements, and thus they lack adequate terms to
triumph over any anti-software-freedom terms of the overarching license.
For example, if I take a 100% ISC-licensed program and build a
binary from it, nothing in the ISC license prohibits me from imposing this
license on you: “you may not redistribute this binary
commercially”. Thus, even if I also say to you: “but also, if
the ISC license grants rights, my aforementioned license does not modify or
reduce those rights”, nothing has changed for you. You still have a
binary that you can’t distribute commercially, and there was no text in the
ISC license to force the trump clause to save you.

Therefore, this whole situation is a simple and clear argument for why
copyleft matters. Copyleft can and does (when someone like me actually
enforces it) prevent such situations. But copyleft is not infinitely
expansive. Nearly every full operating system distribution available
includes an aggregated mix of copylefted, non-copyleft, and often
fully-proprietary userspace applications. Nearly every company that
distributes them wraps the whole thing with some agreement that restricts
some rights that copyleft defends, and then adds a trump clause that gives
an exception just for FLOSS license compliance. Sadly, I have yet to see a
company trailblaze adoption of a “software freedom
preservation” clause that guarantees copyleft-like compliance for
non-copylefted programs and packages. Thus, the problem with Ubuntu is
just a particularly bad example of what has become a standard industry
practice by nearly every “open source” company.

How badly these practices impact software freedom depends on the
strictness and detailed terms of the overarching license
(and not the contents of the trump clause itself; they are
generally isomorphic0). The task of analyzing and
rating “relative badness” of each overarching licensing
document is monumental; there are probably thousands of different ones in
use today. Matthew Garrett points out why Canonical, Ltd.’s is
particularly bad, but that doesn’t mean there aren’t worse (and better)
situations of a similar ilk. Perhaps our next best move is to use copyleft
licenses more often, so that the trump clauses actually do more.

In other words, as long as there is non-copylefted software aggregated in a
given distribution of an otherwise Free Software system, companies will
seek to put non-Free terms on top of the non-copylefted parts, To my
knowledge, every distribution-shipping company (except for
extremely rare, Free-Software-focused companies like ThinkPenguin) place
some kind of restrictions in their business terms for their enterprise
distribution products. Everyone seems to be asking me today to build the
“worst to almost-benign” ranking of these terms, but I’ve
resisted the urge to try. I think the safe bet is to assume that if you’re
looking at one of these trump clauses, there is some sort of
software-freedom-unfriendly restriction floating around in the broader
agreement, and you should thus just avoid that product entirely. Or, if
you really want to use it, fork it from source and relicense the
non-copylefted stuff under copyleft licenses (which is permitted by nearly
all non-copyleft licenses), to prevent future downstream actors from adding
more restrictive terms. I’d even suggest this as a potential solution to
the current Ubuntu problem (or, better yet, just go back upstream to Debian
and do the same :).

Finally, IMO the biggest problem with these “overarching licenses
with a trump clause” is their use by companies who herald “open
source” friendliness. I suspect the community ire comes from a sense
of betrayal. Yet, I feel only my usual anger at proprietary software here;
I don’t feel betrayed. Rather, this is just another situation that proves
that
saying you are an “open source company” isn’t enough;
only the company’s actions and “fine print” terms matter. Now
that open source has really succeeded at coopting software freedom,
enormous effort is now required to ascertain if any company respects your
software freedom. We must ignore the ballyhoo of “community
managers” and look closely at the real story.

0Despite Canonical,
Ltd.’s use of a trump clause, I don’t think these various trump
clauses are canonically isomorphic. There is no natural mapping
between these various trump clauses, but they all do have the same
effect: they assure that when the overarching terms conflict with
the a FLOSS license, the FLOSS license triumphs over the
overarching terms, no matter what they are. However, the
potential relevance of the phrase “canonical
isomorphism” here is yet another example why it’s confusing
and insidious that Canonical, Ltd. insisted so strongly
on using
canonical in a non-canonical way.

Thoughts on Canonical, Ltd.’s Updated Ubuntu IP Policy

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2015/07/15/ubuntu-ip-policy.html

Most of you by now have probably
seen Conservancy’s
and FSF’s
statements regarding
the today’s
update to Canonical, Ltd.’s Ubuntu IP Policy. I have a few personal
comments, speaking only for myself, that I want to add that don’t appear
in the FSF’s nor Conservancy’s analysis. (I wrote nearly all of
Conservancy’s analysis and did some editing on FSF’s analysis, but the
statements here I add are my personal opinions and don’t necessarily
reflect the views of the FSF nor Conservancy, notwithstanding that I have
affiliations with both orgs.)

First of all, I think it’s important to note the timeline: it took two
years of work by two charities to get this change done. The scary thing is
that compared to their peers who have also violated the GPL, Canonical,
Ltd. acted rather quickly.
As Conservancy
pointed out regarding the VMware lawsuit, it’s not uncommon for these
negotiations to take even four years before we all give up and have to file
a lawsuit. So, Canonical, Ltd. resolved the matter at least twice
as fast as VMware, and they deserve some credit for that — even if
other GPL violators have set the bar quite low.

Second, I have to express my sympathy for the positions on this matter
taken by Matthew
Garrett and Jonathan
Riddell. Their positions show clearly that, while the GPL violation is
now fully resolved, the community is very concerned about what the happens
regarding non-copylefted software in Ubuntu, and thus Ubuntu as a
whole.

Realize, though, that these trump clauses are widely used throughout the
software industry. For example, electronics manufacturers who ship an
Android/Linux system with standard, disgustingly worded, forbid-everything
EULA usually include a trump clause not unlike Ubuntu’s. In such systems,
usually, the only copylefted program is the kernel named Linux. The rest
of the distribution includes tons of (now proprietarized) non-copylefted
code from Android (as well as a bunch of born-proprietary applications
too). The trump clause assures the software freedom rights for that one
copylefted work present, but all the non-copylefted ones are subject to the
strict EULA (which often includes “no reverse engineer
clauses”, etc.). That means if the electronics company did change
the Android Java code in some way, you can’t even legally reverse engineer
it — even though it was Apache-licensed by upstream.

Trump clauses are thus less than ideal because they achieve compliance
only by allowing a copyleft to prevail when the overarching license
contradicts specific requirements, permissions, or rights under copyleft.
That’s acceptable because copyleft licenses have many important clauses
that assure and uphold software freedom. By contrast, most non-copyleft
licenses have very few requirements, and thus they lack adequate terms to
triumph over any anti-software-freedom terms of the overarching license.
For example, if I take a 100% ISC-licensed program and build a
binary from it, nothing in the ISC license prohibits me from imposing this
license on you: “you may not redistribute this binary
commercially”. Thus, even if I also say to you: “but also, if
the ISC license grants rights, my aforementioned license does not modify or
reduce those rights”, nothing has changed for you. You still have a
binary that you can’t distribute commercially, and there was no text in the
ISC license to force the trump clause to save you.

Therefore, this whole situation is a simple and clear argument for why
copyleft matters. Copyleft can and does (when someone like me actually
enforces it) prevent such situations. But copyleft is not infinitely
expansive. Nearly every full operating system distribution available
includes an aggregated mix of copylefted, non-copyleft, and often
fully-proprietary userspace applications. Nearly every company that
distributes them wraps the whole thing with some agreement that restricts
some rights that copyleft defends, and then adds a trump clause that gives
an exception just for FLOSS license compliance. Sadly, I have yet to see a
company trailblaze adoption of a “software freedom
preservation” clause that guarantees copyleft-like compliance for
non-copylefted programs and packages. Thus, the problem with Ubuntu is
just a particularly bad example of what has become a standard industry
practice by nearly every “open source” company.

How badly these practices impact software freedom depends on the
strictness and detailed terms of the overarching license
(and not the contents of the trump clause itself; they are
generally isomorphic0). The task of analyzing and
rating “relative badness” of each overarching licensing
document is monumental; there are probably thousands of different ones in
use today. Matthew Garrett points out why Canonical, Ltd.’s is
particularly bad, but that doesn’t mean there aren’t worse (and better)
situations of a similar ilk. Perhaps our next best move is to use copyleft
licenses more often, so that the trump clauses actually do more.

In other words, as long as there is non-copylefted software aggregated in a
given distribution of an otherwise Free Software system, companies will
seek to put non-Free terms on top of the non-copylefted parts, To my
knowledge, every distribution-shipping company (except for
extremely rare, Free-Software-focused companies like ThinkPenguin) place
some kind of restrictions in their business terms for their enterprise
distribution products. Everyone seems to be asking me today to build the
“worst to almost-benign” ranking of these terms, but I’ve
resisted the urge to try. I think the safe bet is to assume that if you’re
looking at one of these trump clauses, there is some sort of
software-freedom-unfriendly restriction floating around in the broader
agreement, and you should thus just avoid that product entirely. Or, if
you really want to use it, fork it from source and relicense the
non-copylefted stuff under copyleft licenses (which is permitted by nearly
all non-copyleft licenses), to prevent future downstream actors from adding
more restrictive terms. I’d even suggest this as a potential solution to
the current Ubuntu problem (or, better yet, just go back upstream to Debian
and do the same :).

Finally, IMO the biggest problem with these “overarching licenses
with a trump clause” is their use by companies who herald “open
source” friendliness. I suspect the community ire comes from a sense
of betrayal. Yet, I feel only my usual anger at proprietary software here;
I don’t feel betrayed. Rather, this is just another situation that proves
that
saying you are an “open source company” isn’t enough;
only the company’s actions and “fine print” terms matter. Now
that open source has really succeeded at coopting software freedom,
enormous effort is now required to ascertain if any company respects your
software freedom. We must ignore the ballyhoo of “community
managers” and look closely at the real story.

0Despite Canonical,
Ltd.’s use of a trump clause, I don’t think these various trump
clauses are canonically isomorphic. There is no natural mapping
between these various trump clauses, but they all do have the same
effect: they assure that when the overarching terms conflict with
the a FLOSS license, the FLOSS license triumphs over the
overarching terms, no matter what they are. However, the
potential relevance of the phrase “canonical
isomorphism” here is yet another example why it’s confusing
and insidious that Canonical, Ltd. insisted so strongly
on using
canonical in a non-canonical way.

Thoughts on Canonical, Ltd.’s Updated Ubuntu IP Policy

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2015/07/15/ubuntu-ip-policy.html

Most of you by now have probably
seen Conservancy’s
and FSF’s
statements regarding
the today’s
update to Canonical, Ltd.’s Ubuntu IP Policy. I have a few personal
comments, speaking only for myself, that I want to add that don’t appear
in the FSF’s nor Conservancy’s analysis. (I wrote nearly all of
Conservancy’s analysis and did some editing on FSF’s analysis, but the
statements here I add are my personal opinions and don’t necessarily
reflect the views of the FSF nor Conservancy, notwithstanding that I have
affiliations with both orgs.)

First of all, I think it’s important to note the timeline: it took two
years of work by two charities to get this change done. The scary thing is
that compared to their peers who have also violated the GPL, Canonical,
Ltd. acted rather quickly.
As Conservancy
pointed out regarding the VMware lawsuit, it’s not uncommon for these
negotiations to take even four years before we all give up and have to file
a lawsuit. So, Canonical, Ltd. resolved the matter at least twice
as fast as VMware, and they deserve some credit for that — even if
other GPL violators have set the bar quite low.

Second, I have to express my sympathy for the positions on this matter
taken by Matthew
Garrett and Jonathan
Riddell. Their positions show clearly that, while the GPL violation is
now fully resolved, the community is very concerned about what the happens
regarding non-copylefted software in Ubuntu, and thus Ubuntu as a
whole.

Realize, though, that these trump clauses are widely used throughout the
software industry. For example, electronics manufacturers who ship an
Android/Linux system with standard, disgustingly worded, forbid-everything
EULA usually include a trump clause not unlike Ubuntu’s. In such systems,
usually, the only copylefted program is the kernel named Linux. The rest
of the distribution includes tons of (now proprietarized) non-copylefted
code from Android (as well as a bunch of born-proprietary applications
too). The trump clause assures the software freedom rights for that one
copylefted work present, but all the non-copylefted ones are subject to the
strict EULA (which often includes “no reverse engineer
clauses”, etc.). That means if the electronics company did change
the Android Java code in some way, you can’t even legally reverse engineer
it — even though it was Apache-licensed by upstream.

Trump clauses are thus less than ideal because they achieve compliance
only by allowing a copyleft to prevail when the overarching license
contradicts specific requirements, permissions, or rights under copyleft.
That’s acceptable because copyleft licenses have many important clauses
that assure and uphold software freedom. By contrast, most non-copyleft
licenses have very few requirements, and thus they lack adequate terms to
triumph over any anti-software-freedom terms of the overarching license.
For example, if I take a 100% ISC-licensed program and build a
binary from it, nothing in the ISC license prohibits me from imposing this
license on you: “you may not redistribute this binary
commercially”. Thus, even if I also say to you: “but also, if
the ISC license grants rights, my aforementioned license does not modify or
reduce those rights”, nothing has changed for you. You still have a
binary that you can’t distribute commercially, and there was no text in the
ISC license to force the trump clause to save you.

Therefore, this whole situation is a simple and clear argument for why
copyleft matters. Copyleft can and does (when someone like me actually
enforces it) prevent such situations. But copyleft is not infinitely
expansive. Nearly every full operating system distribution available
includes an aggregated mix of copylefted, non-copyleft, and often
fully-proprietary userspace applications. Nearly every company that
distributes them wraps the whole thing with some agreement that restricts
some rights that copyleft defends, and then adds a trump clause that gives
an exception just for FLOSS license compliance. Sadly, I have yet to see a
company trailblaze adoption of a “software freedom
preservation” clause that guarantees copyleft-like compliance for
non-copylefted programs and packages. Thus, the problem with Ubuntu is
just a particularly bad example of what has become a standard industry
practice by nearly every “open source” company.

How badly these practices impact software freedom depends on the
strictness and detailed terms of the overarching license
(and not the contents of the trump clause itself; they are
generally isomorphic0). The task of analyzing and
rating “relative badness” of each overarching licensing
document is monumental; there are probably thousands of different ones in
use today. Matthew Garrett points out why Canonical, Ltd.’s is
particularly bad, but that doesn’t mean there aren’t worse (and better)
situations of a similar ilk. Perhaps our next best move is to use copyleft
licenses more often, so that the trump clauses actually do more.

In other words, as long as there is non-copylefted software aggregated in a
given distribution of an otherwise Free Software system, companies will
seek to put non-Free terms on top of the non-copylefted parts, To my
knowledge, every distribution-shipping company (except for
extremely rare, Free-Software-focused companies like ThinkPenguin) place
some kind of restrictions in their business terms for their enterprise
distribution products. Everyone seems to be asking me today to build the
“worst to almost-benign” ranking of these terms, but I’ve
resisted the urge to try. I think the safe bet is to assume that if you’re
looking at one of these trump clauses, there is some sort of
software-freedom-unfriendly restriction floating around in the broader
agreement, and you should thus just avoid that product entirely. Or, if
you really want to use it, fork it from source and relicense the
non-copylefted stuff under copyleft licenses (which is permitted by nearly
all non-copyleft licenses), to prevent future downstream actors from adding
more restrictive terms. I’d even suggest this as a potential solution to
the current Ubuntu problem (or, better yet, just go back upstream to Debian
and do the same :).

Finally, IMO the biggest problem with these “overarching licenses
with a trump clause” is their use by companies who herald “open
source” friendliness. I suspect the community ire comes from a sense
of betrayal. Yet, I feel only my usual anger at proprietary software here;
I don’t feel betrayed. Rather, this is just another situation that proves
that
saying you are an “open source company” isn’t enough;
only the company’s actions and “fine print” terms matter. Now
that open source has really succeeded at coopting software freedom,
enormous effort is now required to ascertain if any company respects your
software freedom. We must ignore the ballyhoo of “community
managers” and look closely at the real story.

0Despite Canonical,
Ltd.’s use of a trump clause, I don’t think these various trump
clauses are canonically isomorphic. There is no natural mapping
between these various trump clauses, but they all do have the same
effect: they assure that when the overarching terms conflict with
the a FLOSS license, the FLOSS license triumphs over the
overarching terms, no matter what they are. However, the
potential relevance of the phrase “canonical
isomorphism” here is yet another example why it’s confusing
and insidious that Canonical, Ltd. insisted so strongly
on using
canonical in a non-canonical way.

The collective thoughts of the interwebz

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close