[
Lists Home |
Date Index |
Thread Index
]
<bryan>
> I was just thinking about the legal ramifications of namespaces as a way
> to control interoperability. It seems to me that a vendor could, with
> bad motives aplenty, decide to prohibit other companies via exorbitant
> pricing/licensing from building tools that processed their namespace
> with the same result as the namespace(or just profit from people
> building such tools).
</bryan>
I believe it is possible to copyright and patent schema. I am not sure
whether one could trademark a namespace. There is probably case law about
trademarking domian names that is relevant, but I have not looked colsely at
this issue.
If one can copyright or patent a schema (or any other xml document), then
one can also exclude/prevent others from using the schema (or any other xml
document).
This is not necesarily a bad thing. Indeed, it can be a very good thing.
I agree with you, it could be used to control interoperability. Company A
who owns schema A could simply exclude all others from writing software
around Schema A. This would make interoperability with Schema A (and
instances based on it) impossible. This is a bad thing for
interoperability, but a for-profit company might reasonably decide to do
this if it deemed this were in its best business interests.
On the other hand, the ability to copyright and patent schema can be a very
good thing for interoperability *if* coupled with an appropriate "general
public license" (I'm using "general public license" in a generic sense).
Copyright and patent rights are used as the basis for a general public
license. The way it works is that a person or organization asserts
intellectual property rights (copyright or patent) in software (in this case
schema) and then grants a world-wide, royalty free, perpetual license to the
public to use the software/schema, provided certain conditions are met.
Conditions vary based on the license, but examples of typical conditions are
(1) licensees must perpetuate the license and bind new users to it (2)
modifications are either (a) prohibited (b) permitted without condition, or
(c) if permitted, modifications must be published back to the source (3)
reference/attribution back to the source must be perpetuated in copies and
derivatives (4) if derivates are permitted, licensees may not charge for
them (5) failure to abide by the terms of the licenses is a breach of the
license.
I have been working on a General Public License (which I'm happy to share
with this list if anyone is interested) tailored specifically for schema in
different namespaces. The main points follow:
1. There is a distinction between (a) Extended (b) Versioned and (c)
Derivative schema.
(a) Extended Schema: If schema A in namespace A is the original schema, then
an extended schema is schema B used with schema A. There is no change to
schema A or elements in namesapce A, but elements from namespace B are
added.
(b) Versioned Schema: A versioned schema is schema A in namespace A with
changes made to it based on a policy or procedure acceptable to the owner(s)
of schema A. An owner might be a company or a standards organization that
owns schema A and wants to create a new version in a managed way.
(c) Derivative Schema: A derivative schema is Schema A in namesapce A that
has been altered.
Under the general public license that I am writing (which could vary based
on someone's needs)
(a) Extended schema are permitted to be used with original schema provided
that extended schema are published back to the owner(s). (Alternatively,
extended schema could be permitted, with no requirement to publish back to
the owner(s).)
(b) Versioned schema are permitted, provided the owners agree.
(c) Derivative schema are not permitted.
The policy behind these conditions is that there is a need to extend and
innovate to meet ever changing business needs, but this need should not
interfere with interoperability and it should now allow people/organizations
to copy schema that have taken real and sweat equity to produce. We do not
want, for example, a return to the browser wars. Software vendors should
not be able to change XHTML (or any other flavor of XML) on a whim. If a
change needs to be made, then XHTML should be changed via a process and
procedure acceptable to the W3C, the owner. However, if a developer wants
to mix elements from a different namespace into XHTML, then I think most
people would agree this should be allowed.
Whether or not extended elements should be published back to the owners is
probalby something to be decided on a case-by-case basis. Suppose Company A
spends five years and a lot of money to create schema/namespace A and builds
software around it. Company B comes along and in one month, uses and
extends schema/namespace A with schema/namespace B and builds software
around it. Company B now has a product that has more features in it (A + B)
than Company A's product. The products are interoperable if Company A
strips out elements/attribute in namespace B, but all of the
features/information from B are lost. In this caes, Company A is quite
reasonable is requring Company B to publish its schema for use by Company A.
I would be interested in any comments you or others have on this topic.
Thanks,
Todd
=========================================
Winchel "Todd" Vincent III
Attorney and Technical Consultant
Project Director, E-CT-Filing Project
Georgia State University College of Law
US Office: 404.651.4297
US Mobile: 404.822.4668
US Mobile: 859.489.8077
US Voice : 770.216.1633
US Fax : 770.216.1633
US Fax : 425.955.1526
AU Mobile: 011 61 0408 606 272
AU Fax : 011 61 2 9475 0147
Email : winchel@mindspring.com
Web : http://e-ct-file.gsu.edu/
|
