On Sat, Jul 24, 2010 at 5:55 AM, Toshio Kuratomi <a.badger@xxxxxxxxx> wrote: > 5) I don't think that we *must* audit an upstream installation to be in > compliance with a free software policy. There are certainly services which > claim to be free software and services which claim to be proprietary (or at > least, make no claims to being free software). With the question of whether > google search is allowable, google has, to the best of my knowledge, never > claimed that their search is free software so it seems a rather obvious > thing to scratch off the list. And when someone challenges the claim that a provider makes, we continue to take the providers word? We are stuck in exactly the position we don't want to be in. This goes back to my comment about underlying guarantees. What do we need to guarantee for ourselves? An escape route from one particular vendor if for whatever reason we no longer want to work with that vendor. What you just said about trusting vendors does nothing to solve the practical problems about running infrastructure that relies on outside vendors. A vendor can claim its open, they get caught in a lie, there's no actually copyright violation so there's no legal lever to force them to open the codebase, and where are we then? Stuck...just as if it were proprietary from the start. Trust but verify. > > 6) So one policy could simply trust what upstream tells us about the > licensing and availability of the code that they are running (we probably > need to make clear that the code that they are running needs to be > available, not just under an open license. That way you can't simply claim > that your unreleased code is under the BSD license, you also have to release > that code.) I guarantee you you will get misinformation because of the complexity of the codebases to run the services. We have this problem already with upstream projects and package generation. Just last week you yourself informed me of a licensing problem with code in one of my packages that I had to clean up..and its been there for years. If somehow we discover a service isn't completely open, or running a set of patches that are not public (which is far far more likely a situation than an out and out lie) the vendor has zero legal requirement to come into compliance with our licensing policy. And unlike me as a packager, where if I didn't take action another packager would have to fix the package i'm primary maintainer on.. there's no way we can fix uncompliant vendors. We get stuck. It is exactly this lack of control of the running service that we must hedge against. Requiring open licensing isn't just a philosophical issue, there are real practical reasons for wanting the freedoms that open licensing has traditionally given users. But web services break the underlying model. Open services don't give users the freedoms to replicate or fork unless they are using the new breed of AGPL-alike licensing. It's simply not enough to require open licensing. We must guarantee our ability to replicate or fork when we can no longer rely on an outside vendor. Public API compliance a codebase we can run locally...those are the two things that we must satisfy to avoid vendor lockin. Services that run AGPL give us that automatically. Services that run apache and BSD codebases do not..even though they are "open." If we don't have the ability to audit, then we are not being intellectually honest about requiring a licensing requirement. Yes it would make me feel better to be able to say we rely on a fully open stack even across the network boundary into other vendors services.. but day-to-day as a workable policy its complete fantasy. It's like the US government trying to mandate that all municipal water systems in Germany have to be fluorinated or US citizen's won't be allowed to travel there. Unless you can get an outside vendor to sign a legally binding agreement (like say the AGPL) which mandates release of code under penalty of law then its pointless to talk about just taking their word for it and moving on. Either we require it and make sure we can verity that the requirement is met.. or we don't require it and we require something else.. like API compliance with a service codebase we can run. Anything in the middle is just asking for trouble down the line. The reality is, out in the wild, your going to see vendors who are like 90% open. Vendors like Facebook. Which as a framework is built on a crapload of open pieces. They even release an open framework version with the proprietary bits stripped out. But to use a real service, you are undoubtedly interacting with proprietary bits behind the scenes(especially if you play farmville..which I know you all do) We have to come to terms with that. Relying on _any_ web services means a lack of control including enforcement of licensing policy (not laws..policy) Its perfectly fine to say we prefer open codebases. It would be reasonable to require AGPL-like web services where the license itself gives us a legal level to get the running source code (even if its difficult in practise to do it). But to state as a policy _requirement_ that we can only interact with "open" services.. without the ability to audit the codebases involved is folly and will only lead to more complicated and torturous decision making in the future when compliance issues come up with a vendor you thought was clean. _______________________________________________ advisory-board mailing list advisory-board@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/advisory-board
