Yes, that's what it means, which I'll definitely admit is odd. I think
there is a massive gray area here that needs to be worked out. I'm not
sure how to work it out.
- James
John Panzer wrote:
[snip]
(Is it just me, or is there too much overloading of metadata here?)
Also, does this mean
Wendy Seltzer wrote:
I'm still not clear on what's happening in 1.1.
1.1 It must also be noted that licenses associated with
feeds or entries using these mechanisms are advisory and
are not, by themselves, legally binding.
Section 1.1 contains two sentences that are, I think, at
On 2006-09-06 02:25:47 -0400, Bob Wyman wrote:
Because of the nature of the tool being used here, a
hyperlink, we must accept that the binding between content and
license is a weak and fragile one. There is no guarantee that the
content of the license associated with a feed at one
On 2006-09-05 15:11:22 -0700, James M Snell wrote:
The relationship is relatively simple. The atom:rights element
is always a human-readable statement of what rights are held over
the feed or entry. It's is the equivalent of saying Copyright
(c) James Snell and cannot be relied upon to
On 2006-09-05 22:02:59 -0700, John Panzer wrote:
Here's my rationale: Atom has explicit support in the core RFC
4287 syntax for 'synthetic' feeds containing entries from
multiple sources produced by multiple authors with different
copyrights. RSS 2.0 doesn't have this core support. So in
* Thomas Roessler [EMAIL PROTECTED] [2006-09-06 11:45]:
On 2006-09-05 15:11:22 -0700, James M Snell wrote:
Take, for instance, Sam Ruby's Planet feed
(http://planet.intertwingly.net/atom.xml). This feed
consists of entries that originated from many different
sources, some of which may
On 2006-09-06 12:21:24 +0200, A. Pagaltzis wrote:
James’ points out that there may be feeds where the feed
publisher has the rights to the feed as a collection, but not to
the content of individual entries. Since these cases exist, it
would be a bad idea for the licence to inherit from the
The problem with specifying a per-feed default license is that there is
currently no way of explicitly indicating that an entry does not have a
license or that any particular entry should not inherit the default
feed-level license.
- james
Thomas Roessler wrote:
On 2006-09-05 22:02:59 -0700,
That means that, in some use cases, setting a default is the wrong
thing to do. That's the same limitation you have for atom:rights.
It's a limitation that can be stated in the specification. But I
don't see how it is a limitation that means there must not be a
default license feature available
Bob Wyman wrote:
...
The mostinteresting cases will be those licenses that attempt to assert limitationsto rights which would normally be considered to be granted to consumers offeeds. Such rights would include things like "Fair Use" and "impliedlicenses." It is *vitally* important to our
Thomas Roessler wrote:
It's fine to point out the lack of an enforceable binding on a
technical level, but I don't think this spec is the place to
discuss the legal implications that this might have.
If the spec does not make statements concerning the intended legal
implications of a
On 2006-09-06 12:47:09 -0400, Bob Wyman wrote:
The authors of the specification have, I think, not only
good reason to state their intention but an obligation to do so.
Warning implementers that the use of the license link may not, in
at least some situations and in some legal systems,
At 12:29 PM 9/6/2006, John Panzer wrote:
Bob Wyman wrote:
...
The most
interesting cases will be those licenses that attempt to assert limitations
to rights which would normally be considered to be granted to consumers of
feeds. Such rights would include things like Fair Use and implied
Wendy Seltzer wrote:
The concern about limiting implied licenses is important...
If the rfc encourages people to add licenses, it opens up
the possibility that their explicit terms will contradict
and override what has previously been implied.
This is precisely why I have normally
On Sep 6, 2006, at 7:51 AM, James M Snell wrote:
The problem with specifying a per-feed default license is that
there is
currently no way of explicitly indicating that an entry does not
have a
license or that any particular entry should not inherit the default
feed-level license.
With
Antone Roundy wrote:
With respect to the issue of aggregate feeds, I had thought
that the existence of an atom:source element at the entry
level blocked any inheritance of the feed metadata, but
looking at RFC 4287, I don't see that explicitly stated.
It's not explicit, but it is
Wednesday, September 6, 2006, 11:38:13 AM, you wrote:
So, here's the proposal:
- Use link rel=license/ for entry licenses -- either on the feed
level, setting a default analogous to what atom:rights does, or on
the element level.
I think that there are data modelling issues with this
Le 7 sept. 06 à 01:29, John Panzer a écrit :
This is a critical point. Without this, implementors cannot safely
ignore licenses they don't understand (falling back to things like
fair use if they can't find any licenses that grant additional
copying rights). This means that implementors
18 matches
Mail list logo